Bug 10427

Summary: [3.2 regression] Stack corruption with variable-length automatic arrays and virtual destructors
Product: gcc Reporter: 188527
Component: c++Assignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: gcc-bugs, jbuck
Priority: P3 Keywords: wrong-code
Version: unknown   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:

Description 188527 2003-04-17 20:06:00 UTC
[ Reported to the Debian BTS as report #188527.
  Please CC 188527@bugs.debian.org on replies.
  Log of report can be found at http://bugs.debian.org/188527 ]
	

Regression from 2.95, rechecked with 3.0.4, 3.2 20030415, 3.3
20030415, HEAD 20030329.

the following program compiles (compiled as "g++ stackcorrupt.cpp"), 
but crashes when run. It seems that the stack gets corrupted with that
variable-length array when A class with a virtual function is used
and the length assigning variable(foo) is being changed.

stackcorrupt.cpp:
--snip--
class A {
  public:
  virtual ~A() {}
};

int main(void) {
  int foo=1;
  A bar[foo];
  foo++;
  return 0;
}
--snip-- 

The same problem can also be reproduced by using the compiler from the 
gcc-snapshot (20030314-1) or with the g++-3.0 (3.0.4-13). The g++-2.95
(2.95.4-17) does not have the same problem.

Release:
unknown
Comment 1 Wolfgang Bangerth 2003-04-17 20:38:15 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed. This small variation shows what happens:
    ----------------------
    #include <iostream>
    
    struct A {
        A () { std::cout << "A::A" << std::endl; }
        ~A() { std::cout << "A::~A" << std::endl;}
    };
    
    int main(void) {
      int foo=1;
      A bar[foo];
      foo++;
      return 0;
    }
    ----------------------------
    g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ x.cc
    g/x> ./a.out
    A::A
    A::~A
    A::~A
    
    Ups. If we make the destructor virtual, we have to look
    up the vtable, but since the expected number of objects
    doesn't match the actual number, the vtable pointer is
    wrong, and we jump into Nirvana.
    
    W.
Comment 2 Joe Buck 2003-04-25 20:01:02 UTC
State-Changed-From-To: analyzed->closed
State-Changed-Why: Fixed for the next release (3.3).