c++/8511: (hopefully) reproducible cc1plus SIGSEGV.

Wolfgang Wieser wwieser@gmx.de
Tue Nov 12 13:31:00 GMT 2002


On Sun, 10 Nov 2002 23:03:15 +0100, Volker Reichelt wrote:
> I suppose it's *not* a "Internal compiler error: Segmentation fault".
> Did I get you rught?
>
No, it _is_ an ICE "Segmentation Fault". 
(Sorry if I was unclear on that.)

>My first wild guess would be that the compiler ran out of memory when
>compiling your source. Can you make sure that this is not the reason
>(i.e. by using a swap device that is large enough)?
>
I have 256 Mb RAM and even more swap and I am pretty sure that mem 
shortage is not the problem especially as swap is neraly unused. 
I could analyze strace output (grep for mmap & brk) if needed. 

>You might have hardware problems: for example faulty memory (you could
>try to swap your chips if you have multiple banks of memory). I remember
>one PR where a faulty BIOS was responsible for strange gcc errors
>(are BIOS upgrades available for your board).
>
I am using pretty new Infineon SDRAM, never had any instability problems 
and ran memtest for several hours some time back. Hardware is not the 
source of trouble. (But you're right: Checking the easiest trouble sources 
first is just logical...)

On Sunday 10 November 2002 21:43, Zack Weinberg wrote:
> On Sat, Nov 09, 2002 at 12:33:14PM -0000, wwieser@gmx.de wrote:
> > First of all, I patched toplev.c to not call signal(SIGSEGV,crash_signal)
> > but die of SIGSEGV instead. This makes it possible to find the crash
> > with gdb. [BTW, to ease debugging, I suggest you do not _exit(1) on
> > SIGSEGV/ILL/... and ICE but terminate the program by killing itself via
> > SIGABRT. This way, it gets much easier to debug internal errors.]
>
> I do not understand why you need this.  When I run cc1(plus) under
> GDB and it takes a fatal signal, GDB recovers control at the point of
> the signal, before signal handlers have a chance to run.
>
Oh yes, you are right. 
Ugh, why did I suggest that? 
Ah - still: Doing abort() instead of exit(1) on ICE would make it easier 
debuggable. (Or am I wrong again? - Okay using a breakpoint...)

> For debugging 'plain' ICEs, the thing to do is set a breakpoint on
> internal_error() before running the program.
>
> >       if (type == 0 || TREE_CODE (type) != REFERENCE_TYPE)
> >         {
> > ==>       if (TREE_CODE (TREE_TYPE (val)) == ARRAY_TYPE
> >
> >               || TREE_CODE (TREE_TYPE (val)) == FUNCTION_TYPE
> >               || TREE_CODE (TREE_TYPE (val)) == METHOD_TYPE)
> >
> >             val = default_conversion (val);
> >         }
> >
> >       if (val == error_mark_node)
> >         return error_mark_node;
> >
> > ...
> >
> > (Neither type nor val are NULL.)
>
> There's not enough information here to know what went wrong.  Probably
> TREE_TYPE (val) was an invalid pointer.
>
How can I tell...?

> > ==>   switch (TREE_CODE (t))
> >         {
> >         case IDENTIFIER_NODE:
> >           return do_identifier (t, 0, NULL_TREE);
> >
> > Crash with t=0xa5a5a5a5 (uh, looks suspicious...)
>
> Yeah.  That means the garbage collector ate a piece of live data.
> These are a pain to debug -- even slight changes in the input will
> make the problem vanish.  
>
That's _exactly_ what I am experiencing!
Even if I remove some lines far away which seemingly do 
not have anything to do with the location of the SIGSEGV, the SIGSEGV 
goes away (turns into ordinary ICE). 

> Unfortunately, using the code you posted, I
> cannot reproduce the crash; I see same the ICE in c_expand_expr that
> Volker Reichelt did.  This is very likely to be because the libstdc++
> headers have changed just enough to perturb the bug into going away; I
> don't see any logged changes that could plausibly have fixed the bug.
>
> We need you to give us a preprocessed source file.  Using your
> installation, issue this command:
>
I'll provide you with preorocessed code. 

> g++ -V3.3 -v -save-temps -I. -Wno-non-template-friend -Wno-unused \
>         -ftemplate-depth-30 -c -o spline.o spline.cpp
>
> That should provoke the same crash, but it will produce a file named
> spline.i as a side effect.  Send us that file (compressed! it will be
> huge) and the complete output of the command.
>
Okay. So, first I CVS updated to the current version (20021112) and 
did a complete re-build (rm -f build-dir; build using gcc-3.3). 
[I can build gcc using gcc-3.2, too, if needed, but it's too late today...]
And then, I compiled the attached code (spline.ii) which makes gcc 
SIGSEGV. (ICE: Segmentation fault)

Please see if you can reproduce the crash. 

Regards,
Wolfgang

[I hope it was okay to CC gcc lists when attaching spline.ii.gz.]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: spline.ii.gz
Type: application/x-gzip
Size: 106845 bytes
Desc: Preprocessed source.
URL: <http://gcc.gnu.org/pipermail/gcc-bugs/attachments/20021112/210cbbb7/attachment.bin>


More information about the Gcc-bugs mailing list