Re: memory corruption bug?

[Jean-Pierre Dussault]

Norbert Nemec wrote:

> Have you tried to fiddly around with compiler options? The sacomp optimization
> engine is somewhat buggy, so whenever you want to debug your code, you should
> switch optimization off first and see whether the problem might dissolve by
> itself.

I did, I ran it with -chk and -debug (the standard debugging setup), no
optimization at all, and got the same bug.


>
>
> Also, once you've located the problem in the Sather source code, you might 
> want
> to take a look at the produced ANSI-C code. It is not very readable, but
> commands are translated rather straightforward, so you should be able to
> identify the lines created by that offending command.

I just tried. The following Sather code seems at the origin of the problem:

      --mapDir := arg.mapDir;
      mapDir[0].copy(arg.mapDir[0]);   -- line 142
      mapDir[1].copy(arg.mapDir[1]);   -- line 143

If I use reference copy (uncomment the first line) instead of deeper copy 
(comment
out the last 2 lines), the bug disapears. In all of that, the field mapDir is
never used in the computations! Of course, on other instances, it WILL be 
useful!

I have a workaround in using reference copies, but I believe that deep copies
would be more robust, since I have no control on how someone else will use my
library.

The offending code compiled without optimization (with -chk alone) translates 
into
(mapDir[i] is of type AXE)
/*******************************************/
/* #line 142  "./../IO/../Cloture/../Objet/Util.sa"*/

 L7 = ATTR(self,mapDir);
 L81_=(AXE)ARR((ARRAYAXE)L7,0);
 L9 = L81_;
 L10 = ATTR(arg,mapDir);
 L111_=(AXE)ARR((ARRAYAXE)L10,0);
 AXE_copy_AXE(L9, L111_);
/* #line 143  "./../IO/../Cloture/../Objet/Util.sa"*/

 L12 = ATTR(self,mapDir);
 L131_=(AXE)ARR((ARRAYAXE)L12,1);
 L14 = L131_;
 L15 = ATTR(arg,mapDir);
 L161_=(AXE)ARR((ARRAYAXE)L15,1);
 AXE_copy_AXE(L14, L161_);
/******************************************/

When compiled with optimizations, AXE_copy_AXE gets inlined, and the code is
somewhat more difficult to follow. Since an AXE is a pair (Point_of_origin named
"o", Direction named "d") both represented by ARRAYs of FLTD, the actual copy
involves builtin code for array copies; here follows the optimized code 
generated.
Once again, nothing looks suspect here, but an eventual subtle bug in AREFACOPY.


/******************************************************************/
/* #line 141  "./../IO/../Cloture/../Objet/Util.sa"*/

 L11 = ATTR(self,mapDir);
 L9 = L11;
 L101_=(AXE)ARR((ARRAYAXE)L9,0);
 copy_self = L101_;
/* #line 34
"./../IO/../Cloture/../Objet/../Cinema/../Transfo/../AlgGeo/Lignes.sa"*/

/* #line 141  "./../IO/../Cloture/../Objet/Util.sa"*/

 L21 = ATTR(arg,mapDir);
 L12 = L21;
 L131_=(AXE)ARR((ARRAYAXE)L12,0);
 copy_arg = L131_;
/* #line 35
"./../IO/../Cloture/../Objet/../Cinema/../Transfo/../AlgGeo/Lignes.sa"*/

 L14 = ATTR(copy_self,o);
 L15 = ATTR(copy_arg,o);
 AREFACOPY(L14,L15);
 ;
/* #line 36
"./../IO/../Cloture/../Objet/../Cinema/../Transfo/../AlgGeo/Lignes.sa"*/

 L17 = ATTR(copy_self,d);
 L18 = ATTR(copy_arg,d);
 AREFACOPY(L17,L18);
 ;
/* #line 141  "./../IO/../Cloture/../Objet/Util.sa"*/

/* #line 34
"./../IO/../Cloture/../Objet/../Cinema/../Transfo/../AlgGeo/Lignes.sa"*/

 L201_=(AXE)ARR((ARRAYAXE)L11,1);
 copy_self1 = L201_;
 L221_=(AXE)ARR((ARRAYAXE)L21,1);
 copy_arg1 = L221_;
/* #line 35
"./../IO/../Cloture/../Objet/../Cinema/../Transfo/../AlgGeo/Lignes.sa"*/

 L23 = ATTR(copy_self1,o);
 L24 = ATTR(copy_arg1,o);
 AREFACOPY(L23,L24);
 ;
/* #line 36
"./../IO/../Cloture/../Objet/../Cinema/../Transfo/../AlgGeo/Lignes.sa"*/

 L26 = ATTR(copy_self1,d);
 L27 = ATTR(copy_arg1,d);
 AREFACOPY(L26,L27);
 ;
/******************************************************************/

>
> Another hint: gcc2.95.2 has a bug in the optimization code as well. Do not use
> -O2 on sather code. That bug seems fixed for 2.95.3 but I do not know about
> 2.96

I use "-O" because of that bug, and no, it's not fixed for 2.96.69 (I use the 
RPM
distribution).


>
>
> Ciao,

Thanks,

JPD


>
> Nobbi
>
> On Tue, Mar 06, 2001 at 05:44:19PM +0000, Jean-Pierre Dussault wrote:
> > Hi!
> >
> > A few weeks ago, I sent the following message/question. Our News server
> > got down nearly at the same time, and I did'nt even read my own message
> > from our usual news server. I happened to read an answer (using another
> > news server) suggesting that the bug may originate in gcc version 2.96
> > 20000731, which is a snapshot not officially distributed. I tested my
> > program using gcc2.95.2, and the same bug occurs.
> >
> > Once again, any help will be appreciated,
> >
> > thanks,
> >
> > JPD
> >
> >
> > > Hi!
> > >
> > > I observe a very strange behavior since I added bump mapping
> > > computations in my graphics library. After intensive experimentation and
> > > observation, I am able to produce what appears a memory corruption bug.
> > > However, since the "bug" showed up when adding new features to an
> > > already large project, I really don't see how I could reproduce its
> > > behavior with a small scaled example!
> > >
> > > To implement bump mapping, I added a field, mapDir (a pair of axises
> > > giving the mapping directions). Now, I comment out EVERY use of mapDir
> > > (confirmed using grep on my whole code), so that all I do is to SET and
> > > COPY this field. Now, with the copy, my image is erroneous and  when I
> > > comment out the copy operation, everything is fine. I attach a pair of
> > > images representing hanging tubes showing differences; no bump map
> > > computation is involved in those images.
> > >
> > > Actually, I hit this problem for the first time using a copy operation
> > > of some other field, and thought the problem originated in my code
> > > somewhere. Now that I've isolated the problem to the copy operation of
> > > an UNUSED variable, I am afraid that the problem does'nt lie in my code.
> > >
> > > I use sather-1.2.1, gcc version 2.96 20000731 (Red Hat Linux 7.0),
> > > gc4.14.
> > >
> > > Any help will be appreciated!!!
> > >
> > > Thanks,
> > >
> > > JPD
>
> --
> -- ______________________________________________________
> -- JESUS CHRIST IS LORD!
> --          To Him, even that machine here has to obey...
> --
> -- _________________________________Norbert "Nobbi" Nemec
> -- Hindenburgstr. 44  ...  D-91054 Erlangen  ...  Germany
> -- eMail: <address@hidden>   Tel: +49-(0)-9131-204180