This is the mail archive of the
libstdc++-prs@sourceware.cygnus.com
mailing list for the libstdc++ project.
libstdc++/34: Segmentation fault when resizing a valarry.
- To: libstdc++-gnats at sourceware dot cygnus dot com
- Subject: libstdc++/34: Segmentation fault when resizing a valarry.
- From: jsk29 at cornell dot edu
- Date: 5 Feb 2000 21:02:27 -0000
- Reply-To: jsk29 at cornell dot edu
- Resent-Cc: libstdc++-prs at sourceware dot cygnus dot com
- Resent-Reply-To: libstdc++-gnats@sourceware.cygnus.com, jsk29@cornell.edu
>Number: 34
>Category: libstdc++
>Synopsis: Segmentation fault when resizing a valarry.
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sat Feb 05 13:07:00 PST 2000
>Closed-Date:
>Last-Modified:
>Originator: John Karcz
>Release: gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
Redhat 6.1 on a Pentium 200, gcc 2.95.2 in /usr/local.
>Description:
First, I hope this is the correct place to report an STL
in gcc 2.95.2. If not, please let me know who to contact.
Resizing a valarray of valarrays can cause a segmentation
fault under certain circumstances.
I am very new to using the STL, and to C++ in general. This
is the first large program I have written using the STL, so
this could well be a feature and not a bug. :) However, it
looks like a bug to me, and I can't figure out a reason why
it would occur othersize, so I'm reporting it to the list.
Let me know if you need more information, or if I should
redirect this report to someone else.
>How-To-Repeat:
A test program is included, which should reproduce the
crash. I've also included tha Makefile, so you can see the
(simple) command line switches I used, and a backtrace, in
case that is helpful.
To reproduce the core dump:
1. Define a valarray<valarray<double>>. (I believe it
also works with types other than double, but I haven't
thoroughly tested any other types.)
2. Resize the valarray to some size, say 10.
3. Resize any of the elements of valarray to another size.
(element 5 is resized to size 2 here, but any valarray
element to any size seems to work.)
4. Resize the valarray again, to the _same_ size as
previously. (10 in the case of this example.)
The core dump should occur at this point.
The second resizing of the main valarray must be to the same
size as it was originally set to... if it is set with
resize(9) or resize(11) in this case, rather than
resize(10), no crash occurs.
--------
test.cc:
--------
#include <valarray>
int main(int argc, char * argv[]) {
valarray< valarray<double> > a; // The outer valarray refers to
a.resize(10);
a[5].resize(2);
a.resize(10);
}
---------
Makefile:
---------
all: test
test: test.cc
g++ -pedantic -Wall -g test.cc -o test
clean:
rm -f test *.o *.so
----------
Backtrace:
----------
#0 0x40095117 in memcpy (dstpp=0x8050500, srcpp=0x0, len=16)
at ../sysdeps/generic/memcpy.c:55
#1 0x804d014 in void __valarray_copy<double> (__a=0x0, __n=2, __b=0x8050500)
at /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/../../../../include/g++-3/std/valarray_array.h:69
#2 0x804cfdd in valarray<double>::operator= (this=0x80504d4, __v=@0xbffffc08)
at /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/../../../../include/g++-3/std/std_valarray.h:342
#3 0x804cf7d in void __valarray_fill<valarray<double> > (__a=0x80504ac,
__n=10, __t=@0xbffffc08)
at /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/../../../../include/g++-3/std/valarray_array.h:48
#4 0x804cd96 in valarray<valarray<double> >::resize (this=0xbffffc10, __n=10,
__c={_M_size = 3221224456, _M_data = 0x0})
at /usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.2/../../../../include/g++-3/std/std_valarray.h:535
#5 0x8049370 in main (argc=1, argv=0xbffffc64) at test.cc:9
Current language: auto; currently c
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: