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

infinite loop in Mtype.remove_aliases #6564

Closed
vicuna opened this issue Sep 17, 2014 · 5 comments
Closed

infinite loop in Mtype.remove_aliases #6564

vicuna opened this issue Sep 17, 2014 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Sep 17, 2014

Original bug ID: 6564
Reporter: @mshinwell
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2016-12-07T10:34:45Z)
Resolution: fixed
Priority: high
Severity: major
Version: 4.02.1+dev
Target version: 4.02.1+dev
Fixed in version: 4.02.1+dev
Category: typing

Bug description

Typechecking "module type of", which calls [Mtype.remove_aliases], appears to loop if the user forgets to specify all -I paths necessary to locate all needed .cmi files.

I have three directories: "l1", "l2" and "client".

$ cat l1/foo.ml
let () = Printf.printf "foo"
$ cat l1/l1.ml
module Foo = Foo

$ cat l2/l2.ml
module Foo = L1.Foo

$ cat client/client.ml
module F = L2.Foo
module type S = module type of F

Inside l1:
$ ocamlopt -c foo.ml
$ ocamlopt -c l1.ml

Inside l2:
$ ocamlopt -I ../l1 -c l2.ml

Inside client:
$ ocamlopt -I ../l2 client.ml (note I've forgotten "-I ../l1")

An example backtrace:
#0 0x000000000062907f in caml_string_compare ()
#1 0x00000000004ee6b3 in camlIdent__find_same_1113 ()
#2 0x0000000000500ca9 in camlEnv__find_same_1304 ()
#3 0x00000000005019b2 in camlEnv__find_module_descr_1529 ()
#4 0x0000000000501df3 in camlEnv__find_module_1584 ()
#5 0x0000000000504c60 in camlEnv__scrape_alias_2047 ()
#6 0x000000000053d5e7 in camlMtype__remove_aliases_1631 ()
#7 0x00000000005a1602 in camlTypemod__type_module_type_of_2225 ()
#8 0x000000000059f2f4 in camlTypemod__transl_modtype_1572 ()
#9 0x00000000004a2d28 in camlMisc__may_map_1059 ()
#10 0x000000000059ec57 in camlTypemod__transl_modtype_decl_1574 ()
#11 0x000000000059bda7 in camlTypemod__type_str_item_2052 ()
#12 0x000000000059c4ff in camlTypemod__type_struct_2185 ()
#13 0x000000000059c594 in camlTypemod__type_struct_2185 ()
#14 0x000000000059ffd0 in camlTypemod__type_structure_inner_3437 ()
#15 0x00000000005a1cc6 in camlTypemod__type_implementation_2263 ()
#16 0x00000000004a1a45 in camlOptcompile__comp_1048 ()
#17 0x00000000004a1fcc in camlOptcompile__implementation_1040 ()
#18 0x00000000004494fb in camlOptmain__process_implementation_file_1011 ()
#19 0x0000000000611797 in camlArg__parse_argv_dynamic_1074 () at arg.ml:207
#20 0x0000000000611961 in camlArg__parse_1128 () at arg.ml:214
#21 0x000000000044a6d6 in camlOptmain__main_1437 ()
#22 0x000000000044bbef in camlOptmain__entry ()
#23 0x0000000000446249 in caml_program ()
#24 0x0000000000634246 in caml_start_program ()
#25 0x0000000000635b35 in __libc_csu_init ()
#26 0x000000356a81ed1d in __libc_start_main (main=0x623a24

, argc=4, ubp_av=0x7fffffffdb98, init=, fini=,
rtld_fini=, stack_end=0x7fffffffdb88) at libc-start.c:226
#27 0x0000000000445929 in _start ()

@vicuna
Copy link
Author

vicuna commented Sep 17, 2014

Comment author: @garrigue

Right, I forgot to protect against this case.
This is fixed in 4.02, at revision 15233.

@vicuna
Copy link
Author

vicuna commented Sep 17, 2014

Comment author: @mshinwell

How many other such cases might have been forgotten?
(Thanks for fixing this so quickly!)

@vicuna
Copy link
Author

vicuna commented Sep 17, 2014

Comment author: @garrigue

I don't see what you mean.
As many as the number of lines in the diff?
I try to be careful, but corner cases exists, and only testing can find all of them.
This is indeed particularly difficult when multiple files are involved, as this is much harder to prepare test cases.

Generally speaking, we try to be very careful about soundness bugs, but I admit that the development methods I use do not defend much against loops.

@vicuna
Copy link
Author

vicuna commented Sep 17, 2014

Comment author: @mshinwell

I suppose this just didn't seem like much of a corner case, that's all.

I was wondering if there were any other specific points in the code where a similar error might occur that would be worth reading over again.

@vicuna
Copy link
Author

vicuna commented Sep 17, 2014

Comment author: @garrigue

It might be better qualified as a lapse of concentration: I was certainly aware that Env.scrape_alias never failed (otherwise I should have protected against that), but didn't realize that it meant that it could return the same alias as a result (which is clearly the only non-contradictory solution...)

If you want to check, you are welcome to read all the diff, but unfortunately we have many invariants of this kind all around the code. And non-termination is probably the hardest one to detect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants