2023-12-03 15:56 AEDT

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0000087mercuryBugpublic2008-11-03 14:09
Assigned Tozs 
Product Version 
Target VersionFixed in Version 
Summary0000087: Programs compiled in profdeep grade create currupt Deep.data files.
DescriptionPrograms 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 InformationThis 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.
TagsNo tags attached.
Attached Files




zs (developer)

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
    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)

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)

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
+Issue History