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

Fatal error: exception Out_of_memory, from [Matching] #6412

Closed
vicuna opened this issue May 12, 2014 · 3 comments
Closed

Fatal error: exception Out_of_memory, from [Matching] #6412

vicuna opened this issue May 12, 2014 · 3 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented May 12, 2014

Original bug ID: 6412
Reporter: @mshinwell
Assigned to: @maranget
Status: closed (set by @xavierleroy on 2015-12-11T18:26:56Z)
Resolution: open
Priority: normal
Severity: crash
Platform: Linux x86-64
Version: 4.02.0+dev
Category: back end (clambda to assembly)

Bug description

I can't provide the source code to this example, and will if needs be spend more time tracking the problem down; but I have a source file which fails with current trunk as follows. Maybe this is a bug in Matching?

(gdb) bt
#0 0x000000000063d3c2 in caml_raise_out_of_memory ()
#1 0x000000000062e386 in compare_stack_overflow ()
#2 0x000000000062e827 in compare_val ()
#3 0x000000000062ea6e in caml_equal ()
#4 0x00000000005a9bd7 in camlMatching__s_rec_1494 ()
#5 0x00000000005b1c4d in camlMatching__same_actions_1489 ()
#6 0x00000000005b8f34 in camlMatching__combine_variant_2818 ()
#7 0x00000000005ba901 in camlMatching__compile_match_2998 ()
#8 0x00000000005baefe in camlMatching__compile_matching_3096 ()
#9 0x00000000005c29b2 in camlTranslcore__transl_function_1433 ()
#10 0x00000000005c263d in camlTranslcore__transl_function_1433 ()
#11 0x00000000005c263d in camlTranslcore__transl_function_1433 ()
#12 0x00000000005c15a0 in camlTranslcore__event_function_1403 ()
#13 0x00000000005c330c in camlTranslcore__transl_exp0_1424 ()
#14 0x00000000005be30b in camlTranslobj__oo_wrap_1140 ()
#15 0x00000000005bf672 in camlTranslcore__transl_1680 ()
#16 0x00000000005cfd47 in camlTranslmod__transl_store_1520 ()
#17 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
#18 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
#19 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
#20 0x00000000005d01b4 in camlTranslmod__transl_store_1520 ()
#21 0x00000000005d01b4 in camlTranslmod__transl_store_1520 ()
#22 0x00000000005d01b4 in camlTranslmod__transl_store_1520 ()
#23 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
#24 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
#25 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
#26 0x00000000005d2f43 in camlTranslmod__transl_store_structure_1515 ()
#27 0x00000000005bdf15 in camlTranslobj__transl_store_label_init_1126 ()
#28 0x00000000005d3254 in camlTranslmod__transl_store_implementation_1636 ()
#29 0x00000000004a21de in camlOptcompile__comp_1047 ()
#30 0x00000000004a2745 in camlOptcompile__implementation_1039 ()
#31 0x000000000044857b in camlOptmain__process_implementation_file_1011 ()
#32 0x0000000000600dc7 in camlArg__parse_argv_dynamic_inner_1258 ()
#33 0x0000000000600f9e in camlArg__parse_1149 ()
#34 0x0000000000449756 in camlOptmain__main_1431 ()
#35 0x000000000044ac1d in camlOptmain__entry ()
#36 0x0000000000445369 in caml_program ()
#37 0x000000000063cf4e in caml_start_program ()

@vicuna
Copy link
Author

vicuna commented May 12, 2014

Comment author: @alainfrisch

I assume this is related to the switch from Lambda.same to Lambda.make_key + the use of the generic comparison. I did not check if there are other possible candidate for introducing a cycle in lambda terms, but there is at least the occurrence of Types.type_expr under Lev_after. This shows that we should probably not rely on the generic comparison... To fix this specific instance, it's probably enough to modify the case for Levent in make_key in order to keep only the location in the lambda_event.

@vicuna
Copy link
Author

vicuna commented May 12, 2014

Comment author: @maranget

Alain's analysis looks correct. For the sake of robustness the compiler
should probably avoid calling the generic equality here.
Working on this.

--Luc

@vicuna
Copy link
Author

vicuna commented May 12, 2014

Comment author: @maranget

I have finally commited a simple patch : sharing keys will not
include Levent _. As a consequence, Levent are never shared, which is
a minor inconvennience.

Notice that the compiler still compares keys with Pervasives.compare

--Luc

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