public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "derrick at caltech dot edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/11695] Memory corruption with -O1 and complex ET code
Date: Wed, 30 Jul 2003 01:33:00 -0000	[thread overview]
Message-ID: <20030730013326.30220.qmail@sources.redhat.com> (raw)
In-Reply-To: <20030728180253.11695.derrick@cco.caltech.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


  parent reply	other threads:[~2003-07-30  1:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-28 18:03 [Bug c++/11695] New: " 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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030730013326.30220.qmail@sources.redhat.com \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).