This is the mail archive of the libstdc++-prs@sourceware.cygnus.com mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

libstdc++/34: Segmentation fault when resizing a valarry.



>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:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]