Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

core dump following faulty match using polymorphic variants #2917

Closed
vicuna opened this issue Aug 21, 2001 · 1 comment
Closed

core dump following faulty match using polymorphic variants #2917

vicuna opened this issue Aug 21, 2001 · 1 comment
Labels

Comments

@vicuna
Copy link

vicuna commented Aug 21, 2001

Original bug ID: 491
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: John (Max) Skaller
Version: 3.02 native code i86
OS: Linux
Submission from: proxy3.syd.pacific.net.au (203.27.69.93)

I hope it's not catching. Just after reproducing
David Mentre's segfault, now I'm getting one in my code too ;-)

Data: Ocaml 3.02, Linux, i86 native code compiler, compiled with pthreads
enabled. I am using the bignum module, but no threads, no magic, no marshal,
and no non-standard modules. The application is the Felix compiler.
Parsing and desugaring passes have run (correctly, as far as I can tell)

Noramlly, I'd suspect an infinite recursion, but it happens
very quickly without disk thrashing (I'm running as root),
and all attempts to trace the recursion using prints
have failed (so far). I've just got this code to compile
after a significant rewrite in which I also switched
almost all variant usage to polymorphic variants.

What I am seeing, however, is an incorrect match using polymorphic
variants: here's the debugging output:

typeofindex finds declaration proc print: int = "printf("%d",$1);";
Found var
:--->declaration proc print: int = "printf("%d",$1);";

That 'found var' comes from

and typeofindex
(dfns:symbol_table_t)
(counter:int ref)
(freg:instantiation_registry_t)
(exclude:int list)
(excluded_dirs:int list)
(index:int)
: btypecode_t =
...
let bt t:btypecode_t =
print_endline ("TYPEOFINDEX binding type " ^ string_of_typecode t);
flush stdout;
let t' = bind_type dfns counter freg env (index::exclude) excluded_dirs sr t
in
print_endline "TYPE BOUND";
t'
in
...
print_endline ("typeofindex finds " ^ string_of_symdef entry id);
flush stdout;
match entry with
....

| SYMDEF_dcl (DCL_var t) ->
print_endline "Found var";
print_endline (":--->" ^ string_of_symdef entry id);
flush stdout;
bt t

but the print routine looks like:
and string_of_symdef entry name = match entry with
.....
| `SYMDEF_dcl d ->
"declaration " ^ string_of_dcl 0 name d
....

and string_of_dcl level name s =
let se e = string_of_expr e in
match s with
...
| DCL_proc (args, code) -> spaces level ^ "proc " ^ name ^ ": " ^ (string_of_typecode (type_of_argtypes args)) ^ " = " ^ string_of_string code ^ ";" ... | DCL_var (ty) ->
spaces level ^
"var " ^ name ^ ": " ^ string_of_typecode ty ^ ";"

The diagnostic listed is the last thing I see before the segfault.
The next call,

bt t

should have executed:

print_endline ("TYPEOFINDEX binding type " ^ string_of_typecode t);
flush stdout;

but hasn't. It would probably have crashed if it did,
since the type of the variant being passed is wrong.
(Did it crash forming the closure?)

The routine, is, in fact, analysing the "proc print" entry,
so the diagnostic output is correct, and it's the match
in the 'typeofindex' routine that is failing.

--
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix http://felix.sourceforge.net
Literate Programming tool Interscript http://Interscript.sourceforge.net

@vicuna
Copy link
Author

vicuna commented Aug 30, 2001

Comment author: administrator

Need full source code to investigate.

@vicuna vicuna closed this as completed Aug 30, 2001
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant