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

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: gcc-gnats@gcc.gnu.org, anderson@ligo.caltech.edu, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/5396: ifstream read()'s data multiple times on Solaris
Date: Thu, 11 Apr 2002 18:22:25 -0700

 Almost certainly related to libstdc++/4150
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4150 
 
 

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

[jason]

Synopsis: ifstream read()'s data multiple times on Solaris

Responsible-Changed-From-To: unassigned->jason
Responsible-Changed-By: jason
Responsible-Changed-When: Tue Apr 23 05:24:56 2002
Responsible-Changed-Why:
    got it
State-Changed-From-To: analyzed->closed
State-Changed-By: jason
State-Changed-When: Tue Apr 23 05:24:56 2002
State-Changed-Why:
    Fixed for 3.1 by same patch as 4150.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5396

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

[Craig Rodrigues]

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

From: Craig Rodrigues <rodrigc@attbi.com>
To: jakub@unthought.net, 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:48:52 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5396
 
 Submitted by jakub@unthought.net:
 
 
  Hello all,
  
  I am seeing an error possibly related to PR 5936:
  
  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.
  
  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=
  )
  
  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.
  
  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.
  
  With GCC-3.0.4 and GNU binutils 2.12, I get:
  
  #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;
  
  Compiler configuration:
  
  $ 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
  
  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).
  
  Oh, and my system is:
  $ uname -a
  SunOS sol 5.8 Generic_108528-05 sun4u sparc SUNW,Ultra-1
  
  Any ideas ?   Need more info ? Anything I can try/test ?  I will try the =
  head=20
  of the 3.1 branch today.
  
  Cheers,
  
   / jakob
  
 
 

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

[Craig Rodrigues]

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

From: Craig Rodrigues <rodrigc@attbi.com>
To: jakub@unthought.net, 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:40:40 -0400

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5396
 
 
 Submitted by jakub@unthought.net:
 
 
 
 On Thu, Apr 18, 2002 at 07:58:11AM -0400, Andras Pataki wrote:
  > 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
  >             107733 - Solaris 2.6
  >             106950 - Solaris 7
  >             109147 - Solaris 8
  >
 
 Great !  Thanks, I will give this a try over the weekend.
 
 So far I have solved the problem by simple changing the structure of
 the exceptions that I throw.
 
 Previously, the exception that caused the problem was a class inherited
 from another class, again inherited from a base.  By only throwing 
 exceptions
 inherited directly from the base, the problem disappears.
 
 Thanks,
 
    / jakob
 

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

[Craig Rodrigues]

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
 

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

[Stuart Anderson]

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

From: Stuart Anderson <sba@srl.caltech.edu>
To: Richard Henderson <rth@redhat.com>
Cc: Stuart Anderson <sba@srl.caltech.edu>, gcc-gnats@gcc.gnu.org,
        anderson@ligo.caltech.edu, gcc-bugs@gcc.gnu.org
Subject: Re: libstdc++/5396: ifstream read()'s data multiple times on Solaris
Date: Fri, 12 Apr 2002 11:33:03 -0700 (PDT)

 According to Richard Henderson:
 > On Fri, Apr 12, 2002 at 08:11:28AM -0700, Stuart Anderson wrote:
 > > However, PR4150 is for i686-pc-linux-gnu whereas PR5396 is explicitly for
 > > Solaris8 and not on a RedHat7.1 Linux.
 > 
 > So?  It can still be the same underlying problem.
 > 
 
 Yes it can be common problem, but I doubt it. What I should have said
 is that the test case for PR5396 does show the same bug on RH7.1 Linux
 but instead works perfectly.
 
 -- 
 Stuart Anderson  sba@srl.caltech.edu  http://www.srl.caltech.edu/personnel/sba

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

[Richard Henderson]

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

From: Richard Henderson <rth@redhat.com>
To: Stuart Anderson <sba@srl.caltech.edu>
Cc: gcc-gnats@gcc.gnu.org, anderson@ligo.caltech.edu, gcc-bugs@gcc.gnu.org
Subject: Re: libstdc++/5396: ifstream read()'s data multiple times on Solaris
Date: Fri, 12 Apr 2002 09:49:49 -0700

 On Fri, Apr 12, 2002 at 08:11:28AM -0700, Stuart Anderson wrote:
 > However, PR4150 is for i686-pc-linux-gnu whereas PR5396 is explicitly for
 > Solaris8 and not on a RedHat7.1 Linux.
 
 So?  It can still be the same underlying problem.
 
 
 r~

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

[Stuart Anderson]

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

From: Stuart Anderson <sba@srl.caltech.edu>
To: Richard Henderson <rth@redhat.com>
Cc: gcc-gnats@gcc.gnu.org, anderson@ligo.caltech.edu, gcc-bugs@gcc.gnu.org
Subject: Re: libstdc++/5396: ifstream read()'s data multiple times on Solaris
Date: Fri, 12 Apr 2002 08:11:28 -0700 (PDT)

 However, PR4150 is for i686-pc-linux-gnu whereas PR5396 is explicitly for
 Solaris8 and not on a RedHat7.1 Linux.
 
 According to Richard Henderson:
 > Almost certainly related to libstdc++/4150
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=4150 
 > 
 > 
 
 -- 
 Stuart Anderson  sba@srl.caltech.edu  http://www.srl.caltech.edu/personnel/sba

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

[pme]

Synopsis: ifstream read()'s data multiple times on Solaris

State-Changed-From-To: open->analyzed
State-Changed-By: pme
State-Changed-When: Wed Apr  3 18:32:06 2002
State-Changed-Why:
    Not really analyzed yet, but reproduced with 3.1 sources,
    20020402 prerelease.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5396

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

[anderson]

>Number:         5396
>Category:       libstdc++
>Synopsis:       ifstream read()'s data multiple times on Solaris
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jan 15 15:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Stuart Anderson
>Release:        gcc-3.0.3
>Organization:
>Environment:
SunOS XXX 5.8 Generic_108528-12 sun4u sparc SUNW,Ultra-60
>Description:
The following simple code to read a file using ifstream
results in the following system call chain on Solaris 8
with gcc-3.0.x,

read(8k) lseek(1k absolute) read(8k) lseek(2k absolute) ...

rather than the following from gcc-2.95.3,

read(8k) read(8k) read(8k) ...

Note in the gcc-3.0.x case there are 8 times more
calls to read() than for gcc-2.95.3!

This bug does not occur on a RedHat7.2 machine with
gcc-3.0.3, and has been reproduced on Solaris with
gcc-3.0.1, 3.0.2, and 3.0.3.

The resulting performance hit prevents our project
from using gcc-3.0.x.
>How-To-Repeat:
truss ./a.out /dev/zero

after compiling,

#include<iostream>
#include<fstream>
main(int argc, char *argv[]){
std::cerr << "foo" << std::endl;
std::ifstream in(argv[1]);
for(int i = 0; i < 100; i++){
char data[1024];
in.read(data,1024);
}
}

Here is a section of the truss output that shows the problem:

open("/dev/zero", O_RDONLY)                     = 3
fstat64(3, 0xFFBEF2E0)                          = 0
brk(0x00033140)                                 = 0
brk(0x00035140)                                 = 0
ioctl(3, TCGETA, 0xFFBEF26C)                    Err#6 ENXIO
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192)     = 8192
lseek(3, 0xFFFFE000, SEEK_CUR)                  = 0
llseek(3, 0, SEEK_CUR)                          = 0
lseek(3, 1024, SEEK_CUR)                        = 1024
llseek(3, 0, SEEK_CUR)                          = 1024
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192)     = 8192
lseek(3, 0xFFFFE000, SEEK_CUR)                  = 1024
llseek(3, 0, SEEK_CUR)                          = 1024
lseek(3, 1024, SEEK_CUR)                        = 2048
llseek(3, 0, SEEK_CUR)                          = 2048
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192)     = 8192
lseek(3, 0xFFFFE000, SEEK_CUR)                  = 2048
llseek(3, 0, SEEK_CUR)                          = 2048
lseek(3, 1024, SEEK_CUR)                        = 3072
llseek(3, 0, SEEK_CUR)                          = 3072
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0".., 8192)     = 8192
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: