Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006412OCamlOCaml backend (code generation)public2014-05-12 12:442014-05-12 17:00
Reportershinwell 
Assigned Tomaranget 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionopen 
PlatformLinux x86-64OSOS Version
Product Version4.02.0+dev 
Target VersionFixed in Version 
Summary0006412: Fatal error: exception Out_of_memory, from [Matching]
DescriptionI 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 ()
0000003 0x000000000062ea6e in caml_equal ()
0000004 0x00000000005a9bd7 in camlMatching__s_rec_1494 ()
0000005 0x00000000005b1c4d in camlMatching__same_actions_1489 ()
0000006 0x00000000005b8f34 in camlMatching__combine_variant_2818 ()
0000007 0x00000000005ba901 in camlMatching__compile_match_2998 ()
0000008 0x00000000005baefe in camlMatching__compile_matching_3096 ()
0000009 0x00000000005c29b2 in camlTranslcore__transl_function_1433 ()
0000010 0x00000000005c263d in camlTranslcore__transl_function_1433 ()
0000011 0x00000000005c263d in camlTranslcore__transl_function_1433 ()
0000012 0x00000000005c15a0 in camlTranslcore__event_function_1403 ()
0000013 0x00000000005c330c in camlTranslcore__transl_exp0_1424 ()
0000014 0x00000000005be30b in camlTranslobj__oo_wrap_1140 ()
0000015 0x00000000005bf672 in camlTranslcore__transl_1680 ()
0000016 0x00000000005cfd47 in camlTranslmod__transl_store_1520 ()
0000017 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
0000018 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
0000019 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
0000020 0x00000000005d01b4 in camlTranslmod__transl_store_1520 ()
0000021 0x00000000005d01b4 in camlTranslmod__transl_store_1520 ()
0000022 0x00000000005d01b4 in camlTranslmod__transl_store_1520 ()
0000023 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
0000024 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
0000025 0x00000000005cfd81 in camlTranslmod__transl_store_1520 ()
0000026 0x00000000005d2f43 in camlTranslmod__transl_store_structure_1515 ()
#27 0x00000000005bdf15 in camlTranslobj__transl_store_label_init_1126 ()
0000028 0x00000000005d3254 in camlTranslmod__transl_store_implementation_1636 ()
0000029 0x00000000004a21de in camlOptcompile__comp_1047 ()
#30 0x00000000004a2745 in camlOptcompile__implementation_1039 ()
#31 0x000000000044857b in camlOptmain__process_implementation_file_1011 ()
0000032 0x0000000000600dc7 in camlArg__parse_argv_dynamic_inner_1258 ()
0000033 0x0000000000600f9e in camlArg__parse_1149 ()
0000034 0x0000000000449756 in camlOptmain__main_1431 ()
0000035 0x000000000044ac1d in camlOptmain__entry ()
0000036 0x0000000000445369 in caml_program ()
0000037 0x000000000063cf4e in caml_start_program ()
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0011428)
frisch (developer)
2014-05-12 12:52
edited on: 2014-05-12 12:55

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.

(0011430)
maranget (manager)
2014-05-12 13:54


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

--Luc
(0011431)
maranget (manager)
2014-05-12 17:00
edited on: 2014-05-12 17:02

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


- Issue History
Date Modified Username Field Change
2014-05-12 12:44 shinwell New Issue
2014-05-12 12:52 frisch Note Added: 0011428
2014-05-12 12:55 frisch Note Edited: 0011428 View Revisions
2014-05-12 13:54 maranget Note Added: 0011430
2014-05-12 13:54 maranget Assigned To => maranget
2014-05-12 13:54 maranget Status new => acknowledged
2014-05-12 17:00 maranget Note Added: 0011431
2014-05-12 17:00 maranget Status acknowledged => resolved
2014-05-12 17:02 maranget Note Edited: 0011431 View Revisions


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker