|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000087||mercury||Bug||public||2008-10-29 11:48||2008-11-03 14:09|
|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.|
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
(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
(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.
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.
|Fix committed nov 3 2008.|
|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|