Re: libstdc++/5396: ifstream read()'s data multiple times on Solaris

[Craig Rodrigues <rodrigc@attbi.com>]

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

From: Craig Rodrigues <rodrigc@attbi.com>
To: gcc-gnats@gcc.gnu.org, gcc-prs@gcc.gnu.org, anderson@ligo.caltech.edu,
   gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/5396: ifstream read()'s data multiple times on Solaris
Date: Sat, 20 Apr 2002 08:33:33 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5396
 
 Submitted by: apataki@apataki.dhs.org
 
 Last week I investigated the problem I was experiencing some more and
 found a solution.  We installed a Solaris linker patch (as part of a
 larger patch set) which seems to have solved the problem for me.
 
 Here are the patch numbers for the various versions of Solaris.  It's
 worth giving a try:
              103627 - Solaris 2.5.1=20
              107733 - Solaris 2.6=20
              106950 - Solaris 7=20
              109147 - Solaris 8=20
 
 Andras
 
 
 On Wed, 17 Apr 2002, Jakob [iso-8859-1] =D8stergaard wrote:
 
  >=20
  > Hello all,
  >=20
  > I am seeing an error possibly related to PR 5936:
  >=20
  > Following configurations are affected:
  > GCC-3.0.2 with vendor linker and assembler, with sjlj-exceptions.
  > GCC-3.0.4 with vendor linker and assembler, with and without 
 sjlj-excepti=
 ons
  > GCC-3.0.4 with GNU binutils 2.12, without sjlj-exceptions.
  >=20
  > I have not yet found a working configuration (one that does not 
 expose th=
 e bug=20
  > that I see - any configuration not listed above, is simply not yet 
 tested=
 )
  >=20
  > My problem:  A non-virtual method in a base class throws an 
 exception, ca=
 using=20
  > either a segfault or a bus error, depending on configurations either in=
 =20
  > vec.cc or eh_throw.cc.
  >=20
  > The method throwing the exception can be either in a shared library, 
 or i=
 n the=20
  > main executable (linked statically, but first incrementally linked 
 into a=
 =20
  > library prior to linking into the executable). This makes no difference.
  >=20
  > With GCC-3.0.4 and GNU binutils 2.12, I get:
  >=20
  > #0  0xff24fca0 in __cxa_throw (obj=3D0xfeb19fec, tinfo=3D0x15a038,
  >     dest=3D0xb194c <_ZN6errors16connectionclosedD1Ev>) at eh_throw.cc:63
  > 63        header->unwindHeader.exception_class =3D __gxx_exception_class;
  >=20
  > Compiler configuration:
  >=20
  > $ g++ -v
  > Reading specs from 
 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.0.4/spec=
 s
  > Configured with: ./configure --enable-languages=3Dc,c++ 
 --disable-threads=
 =20
  > --with-as=3D/usr/local/bin/as --with-gnu-as 
 --with-ld=3D/usr/local/bin/ld=
 =20
  > --with-gnu-ld
  > Thread model: single
  > gcc version 3.0.4
  >=20
  > I tried writing a small test program, but weren't successful in that. 
 I h=
 ave=20
  > some hundreds of thousands of lines of C++, two handfulls of 
 processes al=
 l=20
  > using this code, and *one* process exhibiting the problem.  The exact 
 sam=
 e=20
  > code compiles and works with GCC-3.0.1, GCC-3.0.3 (and others) on 
 various=
 =20
  > Intel based systems (RedHat Linux, Debian GNU/Linux, FreeBSD).
  >=20
  > Oh, and my system is:
  > $ uname -a
  > SunOS sol 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-1
  >=20
  > Any ideas ?   Need more info ? Anything I can try/test ?  I will try 
 the =
 head=20
  > of the 3.1 branch today.
  >=20
  > Cheers,
  >=20
  >  / jakob
  >=20
  >=20