[Bug c++/11695] New: Memory corruption with -O1 and complex ET code

[Bug c++/11695] New: Memory corruption with -O1 and complex ET code

[derrick at cco dot caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: Memory corruption with -O1 and complex ET code
           Product: gcc
           Version: 3.2.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: derrick at cco dot caltech dot edu
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: i686-pc-linux-gnu

I think I found a bug in the optimizer. When I compile with -O1, my code crashes with a seg fault. 
Without optimization it works fine. I began to add lots of debugging code, since it seemed to be a 
memory corruption bug. When I add enough instrumentation, the code stops crashing, apparently 
because the optimizer is no longer able to inline a certain function. Of course, it could still be my 
bug, or a bug in Blitz++, but I'm pretty sure it's the compiler.

The problem also happens with gcc-3.3.1-20030720 (the code does not compile with 3.3), but it 
took additional instrumentation code to remove the crash (with a different function that goes from 
inline to non-inline). The output from the instrumentation indicates that the code is munging 
memory either in an if statement or in a member function call. (I was not able to add enough 
instrumentation code to the 3.2.3 version to determine if the crash was due to a similar problem.)

I am attaching the .ii files that compile (along with a few other files) into the crashing executable, 
one for 3.2.3 and one for 3.3.1. At the end of this message are patches that, when applied to the 
appropriate .ii file, produce the files that do not cause the crash. Both patches add a single line of 
code that calls an external dummy function; adding this additional line of code prevents g++ from 
inlining the function (at least as far as I can tell from nm), and untriggers my bug.

I hope you can track this down without the actual executable as that would require several more 
files, libraries, and a copy of Mathematica! I am including output from the death throes of the 
programs in case it helps track down the bug.

Derrick

**********************************************************
Here is what the 3.2.3 program, running under gdb, outputs just before it dies. As you can see, the 
crash occurs a little beyond the point where I add the dummy function
/newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/array-impl.h 956
/newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/listinit.h: 101
/newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/array/ops.cc: 84
/newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/array/eval.cc: 182
/newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/array/ops.cc: 87
/newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/listinit.h: 106

Program received signal SIGSEGV, Segmentation fault.
blitz::MemoryBlockReference<boost::numeric::interval<long double, 
boost::numeric::interval_lib::policies<boost::numeric::interval_lib::rounded_math<long double>, 
boost::numeric::interval_lib::checking_strict<long double> > > >::blockRemoveReference() 
(this=0xbfffe210) at /newman/user2/derrick/gnu/gcc-3.2.3/include/c++/3.2.3/blitz/
memblock.h:218
218             int refcount = --references_;
(gdb) 

*****************************************************************
And some possibly helpful output from gdb:
(gdb) print *this
$5 = {data_ = 0x0, block_ = 0x0, 
  static nullBlock_ = {<MemoryBlock<boost::numeric::interval<long double, 
boost::numeric::interval_lib::policies<boost::numeric::interval_lib::rounded_math<long double>, 
boost::numeric::interval_lib::checking_strict<long double> > > >> = {_vptr.MemoryBlock = 
0x80ef448, data_ = 0x0, dataBlockAddress_ = 0x0, references_ = 2, length_ = 0}, <No data 
fields>}}

Somehow the fields of *this have been overwritten with zeroes.

*******************************************************************
Here is the same from the program I ran under 3.3.1 (not exactly the same program, I've added 
additional debugging output). I have added some comments set off with asterisks. It appears that 
somewhere in the "call" to initialize() memory is getting munged....
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array-impl.h 956
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/listinit.h: 103
<A>this = 0xbfffe3a0, array = 0xbfffe3c0, array.data = 0x404cd008  **** note the value of 
array.data_ here
Unique:/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/ops.cc: 
65
this = 0xbfffe3c0, data 0   ****** suddenly, after only an inlined function call and an if, the value 
to data_ 
has changed to 0 
Dump of 
Array<N5boost7numeric8intervalIeNS0_12interval_lib8policiesINS2_12rounded_mathIeEENS2_15ch
ecking_strictIeEEEEEE, 1>:
ordering_      = 1 [          0 ]
ascendingFlag_ = 1 [          0 ]
base_          = 1 [          0 ]
length_        = 1 [ -2147483648 ]
stride_        = 1 [        257 ]
zeroOffset_    = 0
numElements()  = -2147483648
isStorageContiguous() = 0
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/ops.cc: 84
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 182
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 209
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 246
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 269
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 288
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 290
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 292
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 295
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 300
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 302
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 305
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 319
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 323
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 331
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 333
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 336
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 386
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/eval.cc: 435
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/ops.cc: 87
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/ops.cc: 69
this = 0xbfffe3c0, data 0
Dump of 
Array<N5boost7numeric8intervalIeNS0_12interval_lib8policiesINS2_12rounded_mathIeEENS2_15ch
ecking_strictIeEEEEEE, 1>:
ordering_      = 1 [          0 ]
ascendingFlag_ = 1 [          0 ]
base_          = 1 [          0 ]
length_        = 1 [ -2147483648 ]
stride_        = 1 [        257 ]
zeroOffset_    = 0
numElements()  = -2147483648
isStorageContiguous() = 0
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/listinit.h: 109
Program received signal SIGSEGV, Segmentation fault.
KBEigenvalueEquation<KonarBhatt3DEquation<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Ex
prConstant<double>, 
blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<blitz:
:_bz_BinExprOp<blitz::_bz_ExprConstant<double>, 
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, blitz::_bz_Multiply<double, double> > >, 
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, blitz::_bz_Multiply<double, double> > >, 
blitz::_bz_Expr<blitz::_bz_UnaryClassExprOp2<blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> 
>, NSStruct> >, blitz::_bz_Multiply<double, double> > >, blitz::_bz_Divide<double, double> > >, 
blitz::_bz_Expr<blitz::_bz_BinaryClassExprOp2<blitz::_bz_UnaryClassExprOp2<blitz::_bz_Expr<bli
tz::_bz_ExprIdentity<double> >, NSStruct>, 
blitz::_bz_Expr<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz:
:_bz_ExprConstant<double>, blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, 
blitz::_bz_Multiply<double, double> > >, blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, 
blitz::_bz_Multiply<double, double> > ><blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, 
ClassFunc<double> > >, NSConductivityBase> > > >::Solve(blitz::Array<long double, 1>, 
blitz::_bz_Expr<blitz::_bz_BinaryClassExprOp2<blitz::_bz_UnaryClassExprOp2<blitz::_bz_Expr<bli
tz::_bz_ExprIdentity<double> >, NSStruct>, 
blitz::_bz_Expr<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz:
:_bz_ExprConstant<double>, blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, 
blitz::_bz_Multiply<double, double> > >, blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, 
blitz::_bz_Multiply<double, double> > ><blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, 
ClassFunc<double> > >, NSConductivityBase> ><double, 1>) (this=0xbfffeae0, ic=
      {<MemoryBlockReference<long double>> = {data_ = 0x8114e00, block_ = 0x8114de8, static 
nullBlock_ = {<MemoryBlock<long double>> = {_vptr.MemoryBlock = 0x80f8358, data_ = 0x0, 
dataBlockAddress_ = 0x0, references_ = 9, length_ = 0}, <No data fields>}}, 
<ETBase<blitz::Array<long double, 1> >> = {<No data fields>}, storage_ = {ordering_ = {data_ = 
{0}}, ascendingFlag_ = {data_ = {true}}, base_ = {data_ = {0}}}, length_ = {data_ = {257}}, stride_ = 
{data_ = {1}}, zeroOffset_ = 0}, times=
      {<MemoryBlockReference<double>> = {data_ = 0x8118ea0, block_ = 0x8118e88, static 
nullBlock_ = {<MemoryBlock<double>> = {_vptr.MemoryBlock = 0x80f83c8, data_ = 0x0, 
dataBlockAddress_ = 0x0, references_ = 1, length_ = 0}, <No data fields>}}, 
<ETBase<blitz::Array<double, 1> >> = {<No data fields>}, storage_ = {ordering_ = {data_ = {0}}, 
ascendingFlag_ = {data_ = {true}}, base_ = {data_ = {0}}}, length_ = {data_ = {72}}, stride_ = {data_ 
= {1}}, zeroOffset_ = 0})
    at /newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/
memblock.h:218
218             int refcount = --references_;

********************************************************
Here is an excerpt from the output of the "fixed" program at the same point in its execution:
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array-impl.h 956
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/listinit.h: 103
<A>this = 0xbfffe3a0, array = 0xbfffe3c0, array.data = 0x404cd008
Unique:/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/array/ops.cc: 
65
this = 0xbfffe3c0, data 0x404cd008
Dump of 
Array<N5boost7numeric8intervalIeNS0_12interval_lib8policiesINS2_12rounded_mathIeEENS2_15ch
ecking_strictIeEEEEEE, 1>:
ordering_      = 1 [          0 ]
ascendingFlag_ = 1 [          1 ]
base_          = 1 [          0 ]
length_        = 1 [         72 ]
stride_        = 1 [        257 ]
zeroOffset_    = 0
numElements()  = 72
isStorageContiguous() = 0

*********************************************************
g++-v:
Reading specs from /newman/user2/derrick/gnu/gcc-3.2.3/lib/gcc-lib/i686-pc-linux-gnu/
3.2.3/specs
Configured with: ../gcc-3.2.3/configure --prefix=/newman/user2/derrick/gnu/gcc-3.2.3
Thread model: posix
gcc version 3.2.3
 /newman/user2/derrick/gnu/gcc-3.2.3/lib/gcc-lib/i686-pc-linux-gnu/3.2.3/cc1plus -
fpreprocessed KonarBhattSimEigInt.crashy.ii -quiet -dumpbase KonarBhattSimEigInt.crashy.ii -O1 
-version -o /tmp/cc01HVBw.s
GNU CPP version 3.2.3 (cpplib) (i386 Linux/ELF)
GNU C++ version 3.2.3 (i686-pc-linux-gnu)
        compiled by GNU C version 3.2.3.
 as -V -Qy -o o_files/eg++-latest/3.2.3/O1/KonarBhattSimEigInt.o /tmp/cc01HVBw.s
GNU assembler version 2.11.93.0.2 (i386-redhat-linux) using BFD version 2.11.93.0.2 20020207

*******************************************************
and
Reading specs from /newman/user2/derrick/gnu/gcc-3.3.1-20030720/lib/gcc-lib/i686-pc-
linux-gnu/3.3.1/specs
Configured with: ../gcc-3.3.1-20030720/configure --prefix=/newman/user2/derrick/gnu/gcc-
3.3.1-20030720
Thread model: posix
gcc version 3.3.1 20030720 (prerelease)
 /newman/user2/derrick/gnu/gcc-3.3.1-20030720/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/cc1plus 
-fpreprocessed KonarBhattSimEigInt-3.3.1.crashy.ii -quiet -dumpbase KonarBhattSimEigInt-
3.3.1.crashy.ii -auxbase-strip o_files/eg++-latest/3.3.1/O1/KonarBhattSimEigInt.o -O1 -version 
-o /tmp/cc4ZHhy1.s
GNU C++ version 3.3.1 20030720 (prerelease) (i686-pc-linux-gnu)
        compiled by GNU C version 3.3.1 20030720 (prerelease).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64298
 as -V -Qy -o o_files/eg++-latest/3.3.1/O1/KonarBhattSimEigInt.o /tmp/cc4ZHhy1.s
GNU assembler version 2.11.93.0.2 (i386-redhat-linux) using BFD version 2.11.93.0.2 20020207

**************************************************************
Here is the context diff that makes a non-crashing version for gcc-3.2.3
*** KonarBhattSimEigInt.crashy.ii       Fri Jul 25 20:04:36 2003
--- KonarBhattSimEigInt.noncrashy.ii    Fri Jul 25 19:53:15 2003
***************
*** 49592,49598 ****
  
  
  
! 
      dummyFunc();
      dummyFunc();
      return *this;
--- 49592,49598 ----
  
  
  
!     dummyFunc();
      dummyFunc();
      dummyFunc();
      return *this;

***************************************************************************
Here is the context diff that makes a non-crashing version for gcc-3.3.1
*** KonarBhattSimEigInt-3.3.1.crashy.ii Sun Jul 27 03:54:09 2003
--- KonarBhattSimEigInt-3.3.1.noncrashy.ii      Sun Jul 27 04:25:35 2003
***************
*** 37105,37111 ****
        cerr << "/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/
listinit.h" << ": " << 103 << endl;
        cerr << "<A>this = " << this << ", " << "array = " << &array_
             << ", array.data = " << array_.dataZero() << endl;
! 
        if (wipeOnDestruct_)
          array_.initialize(value_);
        cerr << "/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/
listinit.h" << ": " << 109 << endl;
--- 37105,37111 ----
        cerr << "/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/
listinit.h" << ": " << 103 << endl;
        cerr << "<A>this = " << this << ", " << "array = " << &array_
             << ", array.data = " << array_.dataZero() << endl;
!       dummyFunc();
        if (wipeOnDestruct_)
          array_.initialize(value_);
        cerr << "/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/
listinit.h" << ": " << 109 << endl;

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at cco dot caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at cco dot caltech dot edu  2003-07-28 18:05 -------
Created an attachment (id=4497)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4497&action=view)
Code that compiles to crashing executable with 3.2.3

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at cco dot caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at cco dot caltech dot edu  2003-07-28 18:06 -------
Created an attachment (id=4498)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=4498&action=view)
Code that compiles to crashing executable with 3.3.1

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING


------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-28 18:49 -------
What version of Mathematica is required, I tried with 4.1 but that did not work?
Also I do not have Blitz++ installed at all so there is no way for me to reproduce this.
Also can you provide the full backtrace of when the seg fault occurs rather than just line numbers?
Also does it work with -fno-inline?
Also can you provide the output of "disassemble" when the seg fault occurs?

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4                         |---

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at caltech dot edu  2003-07-30 01:33 -------
Subject: Re:  Memory corruption with -O1 and complex ET code

> What version of Mathematica is required, I tried with 4.1 but that did  
> not work?
>
4.1 is required. However, to make a functional executable you will need  
several other object files and libraries. In addition, the executable  
reads in several input files before doing its work; I can provide all  
of this if it will help. I should also point out that the crash takes  
several minutes (and a lot of output!) before manifesting.

> Also I do not have Blitz++ installed at all so there is no way for me  
> to reproduce this.
>
That's okay, mine is a hacked up version anyway.The relevant stuff  
should be in the preprocessor file, though, even if its in a very  
unintuitive form, right?

> Also can you provide the full backtrace of when the seg fault occurs  
> rather than just line numbers
>
Here is the backtrace:
#0   
KBEigenvalueEquation<KonarBhatt3DEquation<blitz::_bz_Expr<blitz::_bz_Bin 
ExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<blitz::_bz_BinExprO 
p<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_UnaryClassExprOp2<blitz::_bz_Expr<blitz::_bz_ 
ExprIdentity<double> >, NSStruct> >, blitz::_bz_Multiply<double,  
double> > >, blitz::_bz_Divide<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_BinaryClassExprOp2<blitz::_bz_UnaryClassExprO 
p2<blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, NSStruct>,  
blitz::_bz_Expr<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<bli 
tz::_bz_BinExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> >  
 ><blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, ClassFunc<double>  
 > >, NSConductivityBase> > > >::Solve(blitz::Array<long double, 1>,  
blitz::_bz_Expr<blitz::_bz_BinaryClassExprOp2<blitz::_bz_UnaryClassExprO 
p2<blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, NSStruct>,  
blitz::_bz_Expr<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<bli 
tz::_bz_BinExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> >  
 ><blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, ClassFunc<double>  
 > >, NSConductivityBase> ><double, 1>) (this=0xbfffeae0, ic=
       {<MemoryBlockReference<long double>> = {data_ = 0x81166f0, block_  
= 0x81166d8, static nullBlock_ = {<MemoryBlock<long double>> =  
{_vptr.MemoryBlock = 0x80f8498, data_ = 0x0, dataBlockAddress_ = 0x0,  
references_ = 9, length_ = 0}, <No data fields>}},  
<ETBase<blitz::Array<long double, 1> >> = {<No data fields>}, storage_  
= {ordering_ = {data_ = {0}}, ascendingFlag_ = {data_ = {true}}, base_  
= {data_ = {0}}}, length_ = {data_ = {257}}, stride_ = {data_ = {1}},  
zeroOffset_ = 0}, times=
       {<MemoryBlockReference<double>> = {data_ = 0x8119f90, block_ =  
0x8119f78, static nullBlock_ = {<MemoryBlock<double>> =  
{_vptr.MemoryBlock = 0x80f8508, data_ = 0x0, dataBlockAddress_ = 0x0,  
references_ = 1, length_ = 0}, <No data fields>}},  
<ETBase<blitz::Array<double, 1> >> = {<No data fields>}, storage_ =  
{ordering_ = {data_ = {0}}, ascendingFlag_ = {data_ = {true}}, base_ =  
{data_ = {0}}}, length_ = {data_ = {72}}, stride_ = {data_ = {1}},  
zeroOffset_ = 0})
     at  
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/ 
memblock.h:218
#1  0x08051a6a in main (argc=14, argv=0xbfffee50) at  
/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/ 
memblock.h:374
#2  0x4014d1c4 in __libc_start_main () from /lib/libc.so.6

And maybe this is helpful:
  eip = 0x805b14c
     in  
KBEigenvalueEquation<KonarBhatt3DEquation<blitz::_bz_Expr<blitz::_bz_Bin 
ExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<blitz::_bz_BinExprO 
p<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_UnaryClassExprOp2<blitz::_bz_Expr<blitz::_bz_ 
ExprIdentity<double> >, NSStruct> >, blitz::_bz_Multiply<double,  
double> > >, blitz::_bz_Divide<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_BinaryClassExprOp2<blitz::_bz_UnaryClassExprO 
p2<blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, NSStruct>,  
blitz::_bz_Expr<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<bli 
tz::_bz_BinExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> >  
 ><blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, ClassFunc<double>  
 > >, NSConductivityBase> > > >::Solve(blitz::Array<long double, 1>,  
blitz::_bz_Expr<blitz::_bz_BinaryClassExprOp2<blitz::_bz_UnaryClassExprO 
p2<blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, NSStruct>,  
blitz::_bz_Expr<blitz::_bz_Expr<blitz::_bz_BinExprOp<blitz::_bz_Expr<bli 
tz::_bz_BinExprOp<blitz::_bz_ExprConstant<double>,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> > >,  
blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >,  
blitz::_bz_Multiply<double, double> >  
 ><blitz::_bz_Expr<blitz::_bz_ExprIdentity<double> >, ClassFunc<double>  
 > >, NSConductivityBase> ><double, 1>)
      
(/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/ 
memblock.h:218); saved eip 0x8051a6a
  called by frame at 0xbffff498
  source language c++.
  Arglist at 0xbfffe6e8, args: this=0xbfffeae0, ic=
       {<MemoryBlockReference<long double>> = {data_ = 0x81166f0, block_  
= 0x81166d8, static nullBlock_ = {<MemoryBlock<long double>> =  
{_vptr.MemoryBlock = 0x80f8498, data_ = 0x0, dataBlockAddress_ = 0x0,  
references_ = 9, length_ = 0}, <No data fields>}},  
<ETBase<blitz::Array<long double, 1> >> = {<No data fields>}, storage_  
= {ordering_ = {data_ = {0}}, ascendingFlag_ = {data_ = {true}}, base_  
= {data_ = {0}}}, length_ = {data_ = {257}}, stride_ = {data_ = {1}},  
zeroOffset_ = 0}, times=
       {<MemoryBlockReference<double>> = {data_ = 0x8119f90, block_ =  
0x8119f78, static nullBlock_ = {<MemoryBlock<double>> =  
{_vptr.MemoryBlock = 0x80f8508, data_ = 0x0, dataBlockAddress_ = 0x0,  
references_ = 1, length_ = 0}, <No data fields>}},  
<ETBase<blitz::Array<double, 1> >> = {<No data fields>}, storage_ =  
{ordering_ = {data_ = {0}}, ascendingFlag_ = {data_ = {true}}, base_ =  
{data_ = {0}}}, length_ = {data_ = {72}}, stride_ = {data_ = {1}},  
zeroOffset_ = 0}
  Locals at 0xbfffe6e8, Previous frame's sp is 0x0
  Saved registers:
   ebx at 0xbfffe6dc, ebp at 0xbfffe6e8, esi at 0xbfffe6e0, edi at  
0xbfffe6e4, eip at 0xbfffe6ec

(gdb) info frame 1
Stack frame at 0xbffff498:
  eip = 0x8051a6a in main  
(/newman/user2/derrick/gnu/gcc-3.3.1-20030720/include/c++/3.3.1/blitz/ 
memblock.h:374); saved eip 0x4014d1c4
  called by frame at 0xbffff4d8, caller of frame at 0xbfffe6e8
  source language c++.
  Arglist at 0xbffff498, args: argc=14, argv=0xbfffee50
  Locals at 0xbffff498, Previous frame's sp is 0x0
  Saved registers:
   ebp at 0xbffff498, eip at 0xbffff49c
(gdb) info frame 2
Stack frame at 0xbffff4d8:
  eip = 0x4014d1c4 in __libc_start_main; saved eip 0x804c281
  caller of frame at 0xbffff498
  Arglist at 0xbffff4d8, args:
  Locals at 0xbffff4d8, Previous frame's sp is 0x0
  Saved registers:
   ebx at 0xbffff4cc, ebp at 0xbffff4d8, esi at 0xbffff4d0, edi at  
0xbffff4d4, eip at 0xbffff4dc

> Also does it work with -fno-inline?
>
Yes, sorry, I forgot to mention that. -fno-inline cures it.

> Also can you provide the output of "disassemble" when the seg fault  
> occurs?
>
The output of disassemble is quite horrifying and very long (thank you  
C++!), so I am going to send it along as an attachment.

This might also help:
(gdb) info reg
eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0xbfffe310       -1073749232
esp            0xbfffdd00       0xbfffdd00
ebp            0xbfffe6e8       0xbfffe6e8
esi            0x0      0
edi            0x0      0
eip            0x805b14c        0x805b14c
eflags         0x10202  66050
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x0      0
fctrl          0x37f    895
fstat          0x402e   16430
ftag           0xffff   65535
fiseg          0x23     35
fioff          0x805ab51        134589265
foseg          0x2b     43
fooff          0xbfffe33c       -1073749188
fop            0x5e8    1512
xmm0           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm1           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm2           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm3           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm4           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm5           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm6           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm7           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
mxcsr          0x1f80   8064
orig_eax       0xffffffff       -1

The memory is getting munged, however, somewhere earlier, and the crash  
is a symptom. I think I've managed to figure out that this is occurring  
at the location in the assembly file that goes like this:
         .loc 277 64 0
         movl    (%ebx), %eax
         movl    %eax, -2408(%ebp)
         movl    4(%ebx), %eax
         movl    %eax, -984(%ebp)
         movl    8(%ebx), %eax
         movl    %eax, -980(%ebp)
         movl    12(%ebx), %eax
         movl    %eax, -976(%ebp)
         movl    16(%ebx), %eax
         movl    %eax, -972(%ebp)
         movl    20(%ebx), %eax
         movl    %eax, -968(%ebp)
         movl    24(%ebx), %eax
         movl    %eax, -964(%ebp)

I found this by setting a watchpoint on the array.data_ member that you  
see changing in the output from the program and then disassembling  
around that point. Here is the register dump from just after the the  
watchpoint got triggered:

eax            0x0      0
ecx            0x0      0
edx            0x0      0
ebx            0xbfffe2f0       -1073749264
esp            0xbfffdd00       0xbfffdd00
ebp            0xbfffe6e8       0xbfffe6e8
esi            0x404cd008       1078775816
edi            0x0      0
eip            0x805ad8b        0x805ad8b
eflags         0x302    770
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x0      0
fctrl          0x37f    895
fstat          0x402e   16430
ftag           0xffff   65535
fiseg          0x23     35
fioff          0x805ab5d        134589277
foseg          0x2b     43
fooff          0xbfffe33c       -1073749188
fop            0x5e8    1512
---Type <return> to continue, or q <return> to quit---
xmm0           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm1           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm2           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm3           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm4           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm5           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm6           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
xmm7           {f = {0x0, 0x0, 0x0, 0x0}}       {f = {0, 0, 0, 0}}
mxcsr          0x1f80   8064
orig_eax       0xffffffff       -1

So it seems to be "movl    %eax, -980(%ebp)" that is clobbering the  
memory. There seems to be a corresponding bit of code in the .s file  
that you can make from the non-crashing .ii file:
         .loc 277 64 0
.LBB23232:
         movl    (%esi), %eax
         movl    %eax, -124(%ebp)
         movl    4(%esi), %eax
         movl    %eax, -56(%ebp)
         movl    8(%esi), %eax
         movl    %eax, -52(%ebp)
         movl    12(%esi), %eax
         movl    %eax, -48(%ebp)
         movl    16(%esi), %eax
         movl    %eax, -44(%ebp)
         movl    20(%esi), %eax
         movl    %eax, -40(%ebp)
         movl    24(%esi), %eax
         movl    %eax, -36(%ebp)

I tried to actually get the program to break somewhere around this  
point so I could print the register values, but gdb itself kept  
seg-faulting. Hooray.

Derrick

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-30 02:16 -------
One more question can you try "-fno-strict-aliasing"?

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at caltech dot edu  2003-07-30 03:48 -------
Subject: Re:  Memory corruption with -O1 and complex ET code

> One more question can you try "-fno-strict-aliasing"?
>
The code still crashes. But isn't -fstrict-aliasing off anyway under 
-O1?

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From pinskia at physics dot uc dot edu  2003-08-06 19:57 -------
Can you try a 3.4 snapshot?

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at caltech dot edu  2003-08-19 07:01 -------
Subject: Re:  Memory corruption with -O1 and complex ET code

> Can you try a 3.4 snapshot?
>
I am having trouble getting even a trivial C++ program to run with the 
3.4 snapshots. The programs compile, but refuse to run. I am installing 
each gcc release into a different directory and somehow the executable 
is getting very confused as to where to look for its libraries. Have 
you heard of this problem? Should I file a bug report for that too?

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-19 12:47 -------
You set LD_LIBRARY_PATH right?

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at caltech dot edu  2003-08-20 05:19 -------
Subject: Re:  Memory corruption with -O1 and complex ET code

> You set LD_LIBRARY_PATH right?
>
It is set. It has both the stable compiler and the gcc-3.4 compiler in 
it, the stable one coming first. Hmmm... when I switch the order, 
everything seems to work. I can compile with both the snapshot and my 
old compiler. Apparently, I do not fully understand the mysteries of 
LD_LIBRARY_PATH. Is that supposed to happen? I've been using this setup 
since before the days of egcs-1.0 and this is the first time it has 
been a problem.

Well, anyway, now that things are working, I should have an answer to 
your original question in a day or two. The code has a bunch of errors 
that are being caught by the new parser in 3.4, so I need to fix all 
those before I can say.

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-20 22:20 -------
The real reason for the change in respect to LD_LIBRARY_PATH is that GCC uses more shared 
libraries than before (note the C++ ABI is stable for 3.2 and above so it should be able to use the 
3.4 libraries with 3.2 compiled programs).

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[derrick at caltech dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From derrick at caltech dot edu  2003-08-21 11:25 -------
Subject: Re:  Memory corruption with -O1 and complex ET code

> Can you try a 3.4 snapshot?
>
The program crashes when compiled by 3.4-20030813. It still seems to be 
the same sort of crash, in that -fno-inline cures the problem and that 
when I try to pin things down by adding debugging, eventually the crash 
goes away (presumably due to a previously inlined function becoming not 
inlined, but I did not look at the assembly output to verify that as I 
did for the 3.3.1 snapshot).

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-21 11:33:32
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-21 11:33 -------
According to the sumbitter this still happens in 3.4.

[Bug c++/11695] Memory corruption with -O1 and complex ET code

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-30 03:35 -------
There looks like there is invalid code some where but it is hard to find it in the big 
preprocessed source file, also you see that block_ is 0 which usually means there is 
invalid code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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