[Bug c++/21939] New: Corrupted memory with deque of >63 items under gcc-3.4.4

[Bug c++/21939] New: Corrupted memory with deque of >63 items under gcc-3.4.4

[magerman at rentec dot com]

It took me a long time to whittle this down to a small example, but here it is:

#include <iostream>
#include <deque>
#include <memory>

using std::deque;
using std::auto_ptr;

struct A { long x; char y; A() : x(0) {} };

auto_ptr<deque<A> > foo(int l){
  auto_ptr<deque<A> > d(new deque<A>);
  A a, b, c;
  for (int i=0; i<l; i++)
    d->push_back(a);
  return d;
}

int main(int argc, char **argv) 
{
  auto_ptr<deque<A> > d = foo(atoi(argv[1]));
  A a, b, c;
  for (deque<A>::iterator i = d->begin(); i != d->end(); i++) {
    std::cerr << (*i).x << std::endl;
  }
  return 0;
}

$ /work/external/wwc/bin/g++-3.4.4 -v -save-temps -Wall -fno-strict-aliasing -O2
/work/nova/6067/src/foo.C
Reading specs from /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/work/external/wwc/prgcc
--program-suffix=-3.4.4 --enable-threads --with-included-gettext
--enable-languages=c,c++,f77 --with-gnu-as
--with-as=/work/external/wwc/prodbinu216/bin/as --with-gnu-ld
--with-ld=/work/external/wwc/prodbinu216/bin/ld : (reconfigured)
../gcc-3.4.4/configure --prefix=/work/external/wwc/prgcc --program-suffix=-3.4.4
--enable-threads --with-included-gettext --enable-languages=c,c++,f77
--with-gnu-as --with-as=/work/external/wwc/prodbinu216/bin/as --with-gnu-ld
--with-ld=/work/external/wwc/prodbinu216/bin/ld
Thread model: posix
gcc version 3.4.4
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus -E
-quiet -v /work/nova/6067/src/foo.C -mcpu=v7 -Wall -fno-strict-aliasing -O2 -o
foo.ii
ignoring nonexistent directory
"/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../sparc-sun-solaris2.8/include"
#include "..." search starts here:
#include <...> search starts here:
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/sparc-sun-solaris2.8
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../../../include/c++/3.4.4/backward
 /usr/local/include
 /work/external/wwc/prgcc/include
 /work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/include
 /usr/include
End of search list.
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/cc1plus
-fpreprocessed foo.ii -quiet -dumpbase foo.C -mcpu=v7 -auxbase foo -O2 -Wall
-version -fno-strict-aliasing -o foo.s
GNU C++ version 3.4.4 (sparc-sun-solaris2.8)
        compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
 /work/external/wwc/prodbinu216/bin/as --traditional-format -V -Qy -s -xarch=v8
-o foo.o foo.s
GNU assembler version 2.16 (sparc-sun-solaris2.8) using BFD version 2.16
 /work/external/wwc/prgcc/libexec/gcc/sparc-sun-solaris2.8/3.4.4/collect2 -V -Y
P,/usr/ccs/lib:/usr/lib -rpath-link /usr/lib -Qy
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crt1.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crti.o
/usr/ccs/lib/values-Xa.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtbegin.o
-L/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4 -L/usr/ccs/bin
-L/usr/ccs/lib
-L/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/../../.. foo.o
-lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc -lc
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtend.o
/work/external/wwc/prgcc/lib/gcc/sparc-sun-solaris2.8/3.4.4/crtn.o
GNU ld version 2.16
  Supported emulations:
   elf32_sparc
   elf64_sparc

$

If I run this program with the argument greater than 64, it prints out 63 zeros,
followed by the number 513, followed by more zeros.  If I run it with the
argument 64, it does the same and then SEGVs.

This is as simple an example as I can produce.  The following simplifications
cause the program to behave properly:
1. removing the auto_ptr
2. removing the -fno-strict-aliasing
3. removing any of the unused local variables
4. moving the code from foo() into main
5. making the iterator a const_iterator
6. using -fno-unit-at-a-time
7. replacing -O2 with -O1

Please let me know if you need any more information.

-- David Magerman
magerman@rentec.com

-- 
           Summary: Corrupted memory with deque of >63 items under gcc-3.4.4
           Product: gcc
           Version: 3.4.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: magerman at rentec dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c++/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

[magerman at rentec dot com]

------- Additional Comments From magerman at rentec dot com  2005-06-06 21:25 -------
Created an attachment (id=9043)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9043&action=view)
the preprocessed file that triggers the bug


-- 


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

[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-06 21:27 -------
The last time I saw a bug like this, it was actually a bug in the person's code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |middle-end
           Keywords|                            |wrong-code


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

[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

[magerman at rentec dot com]

------- Additional Comments From magerman at rentec dot com  2005-06-06 22:46 -------
(In reply to comment #2)
> The last time I saw a bug like this, it was actually a bug in the person's code.

I wish it were true.  We've got this code (well, a more complicated version of
it) working optimized (-O3) and unoptimized under two different compilers
(gcc-2.9.5.2 and gcc-3.2) on two different OSes (Linux and Solaris).  The
example is pretty simple and straight-forward.  It's hard to see where there can
be a bug in the code.


-- 


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

[Bug middle-end/21939] Corrupted memory with deque of >63 items under gcc-3.4.4

[pcarlini at suse dot de]

------- Additional Comments From pcarlini at suse dot de  2005-06-06 23:01 -------
Maybe (a wild guess) Andrew refers to apparently similar problems that may occur
with std::sort, when the comparison doesn't fulfil the strict weak ordering reqs,
like libstdc++/18640. Those are user errors, definitely.

-- 


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

[ebotcazou at gcc dot gnu dot org]

------- Additional Comments From ebotcazou at gcc dot gnu dot org  2005-06-07 06:46 -------
Yup, segfaults for 64 on x86-64 too with 3.4.5pre:

Program received signal SIGSEGV, Segmentation fault.
main (argc=-1781549440, argv=0x0) at stl_deque.h:134
134           { return *_M_cur; }


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
  GCC build triplet|sparc-sun-solaris2.8        |
   GCC host triplet|sparc-sun-solaris2.8        |
 GCC target triplet|sparc-sun-solaris2.8        |
      Known to fail|                            |3.4.5
      Known to work|                            |3.3.2 4.0.0 4.1.0
   Last reconfirmed|0000-00-00 00:00:00         |2005-06-07 06:46:35
               date|                            |
            Summary|Corrupted memory with deque |[3.4 Regression] corrupted
                   |of >63 items under gcc-3.4.4|memory with deque of >63
                   |                            |items


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

[fuzzypoint at yahoo dot com]

------- Additional Comments From fuzzypoint at yahoo dot com  2005-06-07 22:19 -------
(In reply to comment #5)
> Yup, segfaults for 64 on x86-64 too with 3.4.5pre:
> 
> Program received signal SIGSEGV, Segmentation fault.
> main (argc=-1781549440, argv=0x0) at stl_deque.h:134
> 134           { return *_M_cur; }
> 

I'm having similar trouble in x86_64 as well.
Tried the above sample on x86_64 and can confirm.  
I modified the program above
a bit and it seems like deque::operator++ is at fault (or badly compiled).

First the modified sample program
------------------------------------------------------------
#include <iostream>
#include <deque>
#include <memory>

using std::deque;
using std::auto_ptr;

static char c = 0;
struct A { long x; char y; A() : x(0),y(c++) {} };

auto_ptr<deque<A> > foo(int l){
  auto_ptr<deque<A> > d(new deque<A>);
  for (int i=0; i<l; i++)
    d->push_back(A());
  return d;
}

struct v { void *a, *b, *c, *d; };

void foo();

int main(int argc, char **argv) 
{
  auto_ptr<deque<A> > d = foo(atoi(argv[1]));
  A a;
  std::cerr << &*d->begin() << " " << &*d->end() << " "
	    << &*d->end()-&*d->begin() << std::endl;
  for (deque<A>::iterator i = d->begin(); i != d->end(); ++i) {
    std::cerr << i->x << ' ' << (int)i->y
	      << " v=" << &*i  
              << " cur=" << ((v*)&i)->a 
              << " first=" << ((v*)&i)->b 
              << " last=" << ((v*)&i)->c 
              << " node=" << ((v*)&i)->d 
              << std::endl;
    if( i->y == 31 )
      foo();
  }
  return 0;
}

void foo() { std::cerr << "faulty ++ is next" << std::endl;}
-----------------------------------------

compiled on x86_64 with g++-3.4.4 -O2 -fno-strict-aliasing I get
$ ./runtest 32
0x6007c0 0x6009d0 33
0 0 v=0x6007c0 cur=0x6007c0 first=0x6007c0 last=0x6009c0 node=0x600788
0 1 v=0x6007d0 cur=0x6007d0 first=0x6007c0 last=0x6009c0 node=0x600788
0 2 v=0x6007e0 cur=0x6007e0 first=0x6007c0 last=0x6009c0 node=0x600788
[...]
0 30 v=0x6009a0 cur=0x6009a0 first=0x6007c0 last=0x6009c0 node=0x600788
0 31 v=0x6009b0 cur=0x6009b0 first=0x6007c0 last=0x6009c0 node=0x600788
faulty ++ is next
0 0 v=0x6009c0 cur=0x6009d0 first=0x6009d0 last=0x600bd0 node=0x600790
0 0 v=0x6009e0 cur=0x6009e0 first=0x6009d0 last=0x600bd0 node=0x600790
[...]
0 0 v=0x600bc0 cur=0x600bc0 first=0x6009d0 last=0x600bd0 node=0x600790
0 Segmentation fault


Looks like operator++ somehow jumps over d->end() and continues counting.

Without -fno-strict-aliasing everything seems just fine:

$ ./runtest 32
0x6007c0 0x6009d0 33
0 0 v=0x6007c0 cur=0x6007c0 first=0x6007c0 last=0x6009c0 node=0x600788
0 1 v=0x6007d0 cur=0x6007d0 first=0x6007c0 last=0x6009c0 node=0x600788
[...]
0 30 v=0x6009a0 cur=0x6009a0 first=0x6007c0 last=0x6009c0 node=0x600788
0 31 v=0x6009b0 cur=0x6009b0 first=0x6007c0 last=0x6009c0 node=0x600788
faulty ++ is next

Seems to me like _M_cur = _M_first is forgotten (or evaluated too late?) in
std::deque::operator++()

stl_deque.h:140
      _Self&
      operator++()
      {
	++_M_cur;
	if (_M_cur == _M_last)
	  {
	    _M_set_node(_M_node + 1);
	    _M_cur = _M_first;
	  }
	return *this;
      }


-- 


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

[Bug middle-end/21939] [3.4 Regression] corrupted memory with deque of >63 items

[magerman at rentec dot com]

------- Additional Comments From magerman at rentec dot com  2005-06-10 18:29 -------
On sun-sparc-solaris2.8:

Compiling with -fno-gcse eliminates the problem for both sample programs.

Compiling with -fno-gcse-las eliminates the problem for both sample programs.

Compiling with -fno-gcse-lm causes the original program to infinite loop.

Compiling with -fno-gcse-lm causes Wolfgang Wander's program to always go
one entry past the end of the list, i.e. ./runtest 3 produces the following
output:
  0x22570 0x22588 3
  0 0 v=0x22570 cur=0x22570 first=0x22570 last=0x22770 node=0x21b7c
  0 1 v=0x22578 cur=0x22578 first=0x22570 last=0x22770 node=0x21b7c
  0 2 v=0x22580 cur=0x22580 first=0x22570 last=0x22770 node=0x21b7c
  0 0 v=0x22588 cur=0x22588 first=0x22570 last=0x22770 node=0x21b7c

-- 


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