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

[Wolfgang Wieser <wwieser at gmx dot de>]

On Wednesday 13 November 2002 03:29, Zack Weinberg wrote:
> On Tue, Nov 12, 2002 at 10:25:10PM +0100, Wolfgang Wieser wrote:
> > Ah - still: Doing abort() instead of exit(1) on ICE would make it easier
> > debuggable. (Or am I wrong again? - Okay using a breakpoint...)
>
> Use of exit() happens to be the easiest way to prevent users from
> getting 100MB core dumps (which they will then try to mail to
> gcc-bugs) when ICEs happen.
>
Good argument. Okay, now I see. 

> > > We need you to give us a preprocessed source file.  Using your
> > > installation, issue this command:
> >
> > I'll provide you with preorocessed code.
>
> Using the file you attached, I can now reproduce the crash.  It turns
> out not to be a GC bug, but an access-beyond-end-of-array bug.
>
> [...]
>
> That prevents the invalid access.  Your test case then carries on to
> crash in c_expand_expr, which is the other bug that we already know
> about, and Volker found a reduced test case for.  I'm cc:ing Mark for
> comments, he's a lot more familiar with this part of the compiler than
> I am.  I'm a bit concerned that this does not happen when unrelated
> parts of the code are changed; the original data corruption could be
> even earlier.
>
You're tough! I wish I could find bugs in a huge amount of code as good 
as you...

But as I am not familiar with GCC code at all, I cannot comment on what 
you posted. But data corruption bugs are about the worst things to debug 
(at least in my code...)

> val/internals.hpp: In function `void
>    internal_vect::mult_mv(internal_vect::vector<n>&, const
>    internal_vect::matrix<r, c>&, const internal_vect::vector<c>&) [with int
> r = 4, int c = 4, int N = 3]':
> val/vector.hpp:50:   instantiated from `vect::Vector<N>
> vect::operator*(const vect::Matrix<R, C>&, const vect::Vector<C>&) [with
> int R = 4, int C = 4]' spline.cpp:102:   instantiated from here
> val/internals.hpp:84: internal compiler error: in c_expand_expr, at
> c-common.c: 4319
>
> If Volker's right that the code is invalid, this should be considered
> a more serious case of ice-on-invalid than one where an error message
> came up first.
>
Okay, the fact that one can extract an invalid test case does not necessarily 
mean that the code triggering the action is invalid. I cannot comment a lot 
on that because spline.cpp was written by a friend (all the other code is by 
me) but I have a different test case around which should be valid C++ 
(below). 

Nevertheless, I felt it as a duty to report any SIGSEGV immediately because 
a segmentation fault is a much more critical bug than an ordinary ICE. 

Okay, I just found the e-mail containing a test case triggering a bug in 
c_expand_expr: 

----------------------------snip here---------------------------
template<int N> class A
{
    template<int I,int J> friend int foo();
};

A<0> a;

template<int I,int J> int foo() { return J; }

void bar() { foo<0,0>(); }
----------------------------snip here---------------------------

This test case was generously provided by Volker Reichelt .. :) 
and can be accessed as problem report 6971 (filed by me). 

Volker and me agree that this is valid C++. 
Sorry that I cannot test if this bug is still in gcc (wrong computer here) 
but I am pretty sure because the last time I checked, is was still there 
and it is not marked "closed". 

I'd be pleased if you could fix that some time becuase my template 
code triggers this bug and I currently cannot go on implementing 
my design. (After all, the bug is already 6 months old.)

Regards,
Wolfgang Wieser