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]

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


The following reply was made to PR libstdc++/34; it has been noted by GNATS.

From: Gabriel Dos Reis <Gabriel.Dos-Reis@cmla.ens-cachan.fr>
To: jsk29@cornell.edu
Cc: libstdc++-gnats@sourceware.cygnus.com, libstdc++@sourceware.cygnus.com
Subject: Re: libstdc++/34: Segmentation fault when resizing a valarry.
Date: 06 Feb 2000 00:26:46 +0100

 jsk29@cornell.edu writes:
 
 | >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.
 
 Thank you very much for your bug report.
 
 | 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.)
 
 valarray<valarray<double> > is not expected to work in general,
 because:
 
 26.1/1
   The complex and valarray components are parameterized by the type of
   information they contain and manipulate.  A C++ program shall
   instantiate these components only with a type T that satisfies the
   following requirements
   [...]
   -- If T is a class, its assignment operator, copy and default
   constructors, and destructor shall correspond to each other in the
   following sense: Initialization of raw storage using the default
   constructor, followed by assignment, is semantically equivalent to
   initialization of raw storage using the copy constructor. [...]
 
 valarrays do not meet this requirement.
 
 If you want to build a two dimensional array out of valarray, please
 consider using gslice and gslice_array in conjunction with a plain
 valarray. 
 
 [...]
 
 | #4  0x804cd96 in valarray<valarray<double> >::resize (this=0xbffffc10, __n=10, 
 |     __c={_M_size = 3221224456, _M_data = 0x0})
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 I'm wondering how this can be possible, given:
 
 template<typename _Tp>
 inline valarray<_Tp>::valarray () : _M_size (0), _M_data (0) {}
 
 
 Thanks a lot.
 
 -- Gaby

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