View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
---|---|---|---|---|---|---|---|---|---|
0000087 | mercury | Bug | public | 2008-10-29 11:48 | 2008-11-03 14:09 | ||||
Reporter | pbone | ||||||||
Assigned To | zs | ||||||||
Priority | normal | Severity | major | Reproducibility | sometimes | ||||
Status | resolved | Resolution | fixed | ||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0000087: Programs compiled in profdeep grade create currupt Deep.data files. | ||||||||
Description | Programs compiled in the asm_fast.gc.profdeep grade exit with a message similar to "Not all nodes written out, Deep.data file corrupted". Programs tasted: mercury compiler, mdprof_dump, hello world, and the test suite, they all show the same symptom. | ||||||||
Additional Information | This occurs when using a compiler from roughly 2008-10-27. But not when using a compiler from 2008-10-12. (Tested on taura) The bug has probably existed for a while but has only surfaced recently due to some seemingly-unrelated change. When I have spare time I'll continue to bisect time to track down when exactly this surfaced. | ||||||||
Tags | No tags attached. | ||||||||
Attached Files |
|
Notes | |
zs (developer) 2008-10-31 13:08 |
I don't know why the problem only surfaced recently, but it seems that its underlying cause is a misunderstanding about the import_status of predicates. In integer.m in the library, the predicate integer.to_string calls the function string.++. (a) String.++ is marked (correctly) as opt_imported. (b) The test predicate pred_info_is_imported FAILS for opt_imported predicates. (c) This causes make_rtti_proc_label to put "no" into the pred_is_imported field of the rtti_proc_label for string.++. (d) This rtti_proc_label is put into the element of the call_site_static_data list for integer.to_string that corresponds to the call to string.++ as the rtti_proc_label of the callee. (e) When the time comes to write out the call_site_static structures, layout_out.m invokes make_proc_label_from_rtti to convert this rtti_proc_label in the call_site_static_data to a plain, non-RTTI proc_label. However, since the current module name ("integer") does not match the name of the module that defines the function ("string") AND the function is not marked as imported, make_user_proc_label (invoked from make_proc_label_from_rtti) believes that this means that this module generates code for the callee (as we do for some opt_imported procedures). (f) For procedures for which we generate target code in a different module than their defining module, we generate different labels for them than the label for the code for the procedure in its own module. We derive the name of a procedure's proc_static structure directly from its label, so this difference holds for the names of proc_static structures as well as for labels. (g) This lead to the problem, which was that the call_site_static for this call site referred to the proc_static for string.++ defined in integer.c (as opposed to string.++ defined in string.c), since integer.c did not actually generate code for string.++, there was no such proc_static. This should be a link error, but it isn't, due to the requirement on unix linkers of being compatible with Fortran's ancient semantics (specifically, Fortran's common areas). Instead, the C compiler happily allocates memory for the undefined symbol and fills it with zeros as if it were a proc_static structure. (h) The assertion violation in mercury_deep_profiling.c occurs because the call_site_static refers to this bogus proc_static, but of course no module writes out this proc_static. |
juliensf (administrator) 2008-10-31 16:04 |
I suspect that the reason that the problem has only recently surfaced is that we have only recently started doing deep profiling with inlining enabled. |
zs (developer) 2008-11-03 14:09 |
Fix committed nov 3 2008. |
Issue History | |||
Date Modified | Username | Field | Change |
---|---|---|---|
2008-10-29 11:48 | pbone | New Issue | |
2008-10-31 13:08 | zs | Note Added: 0000154 | |
2008-10-31 16:04 | juliensf | Note Added: 0000155 | |
2008-11-03 14:09 | zs | Status | new => assigned |
2008-11-03 14:09 | zs | Assigned To | => zs |
2008-11-03 14:09 | zs | Status | assigned => resolved |
2008-11-03 14:09 | zs | Resolution | open => fixed |
2008-11-03 14:09 | zs | Note Added: 0000156 |