Bug 135446 - Stack array allocation dynamically resolves size on destruction
Summary: Stack array allocation dynamically resolves size on destruction
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: gcc   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-10-12 19:08 UTC by Craig Lawson
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 19:16:15 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
C++ code (1.09 KB, text/plain)
2004-10-12 19:10 UTC, Craig Lawson
no flags Details

Description Craig Lawson 2004-10-12 19:08:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040924

Description of problem:
Destruction of local array of objects dynamically resolves array size;
the should be stored when array is allocated.

For example, allocate and array on the stack with:

  std::string  list[f()];

When the variable goes out of scope, the array elements are
destructed. But the length of the array comes from invoking f() again!
The compiler should store the allocated size rather than invoke the
sizing function again as the return value could be different.

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


How reproducible:
Always

Steps to Reproduce:
1. Compile attached program with g++
2. Run a.out
   

Actual Results:  Program crashes because sizing function is called a
second time. Perhaps this is a heavy handed demonstration, but that
was the original problem I faced.

Expected Results:  No crash. Proper deallocation.

Additional info:

Failure occurs with:
  g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-42).

Problem does not occur with:
  g++ (GCC) 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6)

Comment 1 Craig Lawson 2004-10-12 19:10:12 UTC
Created attachment 105086 [details]
C++ code

C++ code to demonstrate bug. With comments.

Comment 2 Jakub Jelinek 2004-10-13 16:47:55 UTC
Just FYI, VLAs are not ISO C++.
Seems this was in GCC 3.3 around 2003-04-23 by a patch that was meant
as optimization, not a bug fix, though I don't think such a patch
is suitable for GCC 3.2.3-RH.
Will look into alternatives.

Comment 3 RHEL Product and Program Management 2007-10-19 19:16:15 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.


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