Bug 76314 - GCC3.2 produces wrong code: Destructor called for non-constructed local object
GCC3.2 produces wrong code: Destructor called for non-constructed local object
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
8.0
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-10-19 16:10 EDT by Kristian Spangsege
Modified: 2007-04-18 12:47 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-03 06:16:27 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kristian Spangsege 2002-10-19 16:10:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
In the "top-level" scope of a destructor for some class B a local object of
class A will have its destructor called even if it was never initialized by its
constructor due to a return statement appearing before the declaration of the
local object.

The problem does not occur if the local object and the earlier return statement
is placed in and ordinary method. Also the problem disappears if the entire
destructor body of B is put within an otherwise redundant scope, similarly if
only the declaration of the local object is put into a new scope.

The problem also does not occur with GCC-2.96.

The problem obviously results in core dumps unless one of the mentioned
work-arounds are applied. But this is close to impossible when porting large
applications from earlier versions of gcc.

(I'm utterly amazed about the fact that RedHad has managed to release its RedHat
8.0 entirely base on gcc3.2, when gcc3.2 has susch a lethal bug within it)

Btw. it took me 3 days of reducing 50000 lines of code to around 20 before I was
even close to realizing what the bug was.

Go fix it :-)


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
$ g++ test.C
$ ./a.out

And "test.C" is:

#include <iostream>

struct A
{
  A()  { std::cerr << "c\n"; }
  ~A() { std::cerr << "d\n"; }
};

struct B
{
  ~B()
  {
    if(true) return;
    A a;
  }
};

int main()
{
  B b;
  return 0;
}


Actual Results:  I get the following output:

d

Expected Results:  I should have had no output:


Additional info:

The problem occurs on:
RedHat 8.0 (Full install) on dual Intel Pentium III
And various other hardware configs. with RedHat 8.0
gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)

I would be damned if this bug does not cause segfaults and other nasty behaviour
in some applications shipped with RedHat 8.0 that use
the lethal construct.
Comment 1 Need Real Name 2002-12-08 13:18:11 EST
I have RedHat 8.0 on a Pentium IV and intel motherboard with 60 gig harddrive
and 256 meg memory.  I have transferred some fortran programs from another
RedHat 7.2 system where everything works fine.  The program starts, runs a while
with a lot of disk read/writes and then just crashes.  Maybe this is related?
Comment 2 Kristian Spangsege 2002-12-09 11:20:10 EST
No, I don't think your Fortram problem is related.
The bug I describe above, was tracked down by mark@codesourcery.com <Mark
Mitchell> and is corrected in gcc3.2.1 was has recently been released.
Is I understand it the bug was exclusively related to the C++ frontend of gcc.

For details,check out:
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8287
Comment 3 Richard Henderson 2004-10-03 06:16:27 EDT
Indeed fixed.

Note You need to log in before you can comment on or make changes to this bug.