public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug c++/11695] New: Memory corruption with -O1 and complex ET code
@ 2003-07-28 18:03 derrick at cco dot caltech dot edu
2003-07-28 18:05 ` [Bug c++/11695] " derrick at cco dot caltech dot edu
` (14 more replies)
0 siblings, 15 replies; 16+ messages in thread
From: derrick at cco dot caltech dot edu @ 2003-07-28 18:03 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu @ 2003-07-28 18:05 ` derrick at cco dot caltech dot edu 2003-07-28 18:06 ` derrick at cco dot caltech dot edu ` (13 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: derrick at cco dot caltech dot edu @ 2003-07-28 18:05 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu 2003-07-28 18:05 ` [Bug c++/11695] " derrick at cco dot caltech dot edu @ 2003-07-28 18:06 ` derrick at cco dot caltech dot edu 2003-07-28 18:49 ` pinskia at physics dot uc dot edu ` (12 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: derrick at cco dot caltech dot edu @ 2003-07-28 18:06 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu 2003-07-28 18:05 ` [Bug c++/11695] " derrick at cco dot caltech dot edu 2003-07-28 18:06 ` derrick at cco dot caltech dot edu @ 2003-07-28 18:49 ` pinskia at physics dot uc dot edu 2003-07-29 20:28 ` pinskia at physics dot uc dot edu ` (11 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: pinskia at physics dot uc dot edu @ 2003-07-28 18:49 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (2 preceding siblings ...) 2003-07-28 18:49 ` pinskia at physics dot uc dot edu @ 2003-07-29 20:28 ` pinskia at physics dot uc dot edu 2003-07-30 1:33 ` derrick at caltech dot edu ` (10 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: pinskia at physics dot uc dot edu @ 2003-07-29 20:28 UTC (permalink / raw) To: gcc-bugs 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 |--- ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (3 preceding siblings ...) 2003-07-29 20:28 ` pinskia at physics dot uc dot edu @ 2003-07-30 1:33 ` derrick at caltech dot edu 2003-07-30 2:16 ` pinskia at physics dot uc dot edu ` (9 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: derrick at caltech dot edu @ 2003-07-30 1:33 UTC (permalink / raw) To: gcc-bugs 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (4 preceding siblings ...) 2003-07-30 1:33 ` derrick at caltech dot edu @ 2003-07-30 2:16 ` pinskia at physics dot uc dot edu 2003-07-30 3:49 ` derrick at caltech dot edu ` (8 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: pinskia at physics dot uc dot edu @ 2003-07-30 2:16 UTC (permalink / raw) To: gcc-bugs 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"? ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (5 preceding siblings ...) 2003-07-30 2:16 ` pinskia at physics dot uc dot edu @ 2003-07-30 3:49 ` derrick at caltech dot edu 2003-08-06 19:57 ` pinskia at physics dot uc dot edu ` (7 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: derrick at caltech dot edu @ 2003-07-30 3:49 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (6 preceding siblings ...) 2003-07-30 3:49 ` derrick at caltech dot edu @ 2003-08-06 19:57 ` pinskia at physics dot uc dot edu 2003-08-19 7:01 ` derrick at caltech dot edu ` (6 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: pinskia at physics dot uc dot edu @ 2003-08-06 19:57 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (7 preceding siblings ...) 2003-08-06 19:57 ` pinskia at physics dot uc dot edu @ 2003-08-19 7:01 ` derrick at caltech dot edu 2003-08-19 12:47 ` pinskia at gcc dot gnu dot org ` (5 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: derrick at caltech dot edu @ 2003-08-19 7:01 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (8 preceding siblings ...) 2003-08-19 7:01 ` derrick at caltech dot edu @ 2003-08-19 12:47 ` pinskia at gcc dot gnu dot org 2003-08-20 5:19 ` derrick at caltech dot edu ` (4 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-08-19 12:47 UTC (permalink / raw) To: gcc-bugs 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? ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (9 preceding siblings ...) 2003-08-19 12:47 ` pinskia at gcc dot gnu dot org @ 2003-08-20 5:19 ` derrick at caltech dot edu 2003-08-20 22:20 ` pinskia at gcc dot gnu dot org ` (3 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: derrick at caltech dot edu @ 2003-08-20 5:19 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (10 preceding siblings ...) 2003-08-20 5:19 ` derrick at caltech dot edu @ 2003-08-20 22:20 ` pinskia at gcc dot gnu dot org 2003-08-21 11:25 ` derrick at caltech dot edu ` (2 subsequent siblings) 14 siblings, 0 replies; 16+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-08-20 22:20 UTC (permalink / raw) To: gcc-bugs 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). ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (11 preceding siblings ...) 2003-08-20 22:20 ` pinskia at gcc dot gnu dot org @ 2003-08-21 11:25 ` derrick at caltech dot edu 2003-08-21 11:33 ` pinskia at gcc dot gnu dot org 2003-12-30 4:20 ` pinskia at gcc dot gnu dot org 14 siblings, 0 replies; 16+ messages in thread From: derrick at caltech dot edu @ 2003-08-21 11:25 UTC (permalink / raw) To: gcc-bugs 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). ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (12 preceding siblings ...) 2003-08-21 11:25 ` derrick at caltech dot edu @ 2003-08-21 11:33 ` pinskia at gcc dot gnu dot org 2003-12-30 4:20 ` pinskia at gcc dot gnu dot org 14 siblings, 0 replies; 16+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-08-21 11:33 UTC (permalink / raw) To: gcc-bugs 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [Bug c++/11695] Memory corruption with -O1 and complex ET code 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu ` (13 preceding siblings ...) 2003-08-21 11:33 ` pinskia at gcc dot gnu dot org @ 2003-12-30 4:20 ` pinskia at gcc dot gnu dot org 14 siblings, 0 replies; 16+ messages in thread From: pinskia at gcc dot gnu dot org @ 2003-12-30 4:20 UTC (permalink / raw) To: gcc-bugs ------- 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-12-30 3:35 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-07-28 18:03 [Bug c++/11695] New: Memory corruption with -O1 and complex ET code derrick at cco dot caltech dot edu 2003-07-28 18:05 ` [Bug c++/11695] " derrick at cco dot caltech dot edu 2003-07-28 18:06 ` derrick at cco dot caltech dot edu 2003-07-28 18:49 ` pinskia at physics dot uc dot edu 2003-07-29 20:28 ` pinskia at physics dot uc dot edu 2003-07-30 1:33 ` derrick at caltech dot edu 2003-07-30 2:16 ` pinskia at physics dot uc dot edu 2003-07-30 3:49 ` derrick at caltech dot edu 2003-08-06 19:57 ` pinskia at physics dot uc dot edu 2003-08-19 7:01 ` derrick at caltech dot edu 2003-08-19 12:47 ` pinskia at gcc dot gnu dot org 2003-08-20 5:19 ` derrick at caltech dot edu 2003-08-20 22:20 ` pinskia at gcc dot gnu dot org 2003-08-21 11:25 ` derrick at caltech dot edu 2003-08-21 11:33 ` pinskia at gcc dot gnu dot org 2003-12-30 4:20 ` pinskia at gcc dot gnu dot org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).