[Bug fortran/53015] free_pi_tree(): Unresolved fixup is back

["burnus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-04-17 09:08:51 UTC ---
(In reply to comment #0)
> I get "Internal error - free_pi_tree(): Unresolved fixup" all over the place again, with versions 4.6.2, 4.7.0 and 4.8.0 of gfortran from svn. [...]
> the issue is very elusive: Sometimes it happens when compiling the modules
> themselves, sometimes when compiling a program that uses the modules.
> I have no clue what the error means and the rest of the case seems
> non-deterministic.

The pi_tree is used when reading a module file (.mod). Often, when reading a
symbol from the .mod file, not all pieces of information are available. Thus,
an incomplete symbol is created - and later the missing bits are added. The
information is storied in a binary tree ("pi_tree" as it stores a pointer and
an integer as id). And the ICE (= internal compiler error) occurs if that tree
has a bad status.

There are two kinds of possible problems, leading to such a failure:
(a) The tree is not properly walked (during fixup resolution); that typically
occurs when it is modified while walking the tree - as the modification might
cause a tree rebalancing. 
(b) Freed memory is accessed - which either shouldn't be accessed or shouldn't
be freed. Often the memory (still) contains the correct or at least somewhat
sensible data. [Or some variants of that.]

Both type of problems depend on many details - and not only on the compiler
input but also the hardware, libraries and how the compiler has been compiled.
Tiny differences can cause the program to fail or not to fail. Unfortunately,
it does not make it simple to find the bug.

In this case, my suspicion would be that there is a bug when reading a .mod
file. However, I remember a problem* where symbols where not properly resolved,
leading to writing insufficient data to the .mod file, such that at the end the
ICE occurred when reading the .mod file - but the bug was much earlier. (*
http://gcc.gnu.org/ml/fortran/2011-11/msg00000.html) Unfortunately, debugging
the pi_tree is very difficult as the pointers it contains lack type
information.


I hope that your problem is reproducible, i.e., if you find a test case, it
will more or less reliably also fail on, e.g., my computer. That will make
debugging tremendously easier. You could also try valgrind; there should be no
failure (except of leaking memory). However, I fear that valgrind won't help in
this case.

Other than that, I can only suggest to create a small rest case. For instance
using http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction [please use GCC 4.8
for that]. I do not have any other idea and I fear that even with a small test
case, debugging won't be easy.