This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


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

errno_location & libpthread on Alpha



The following bug report applies also to glibc 2.2 (didn't test
2.2.2pre1 yet).

Any ideas what wrong?

Andreas



Topics:
   libc/2085: Linux threads __errno_location can be linked in without accompanying init code
   Re: libc/2085: Linux threads __errno_location can be linked in 
   libc/2085: Re: libc/2085: Linux threads __errno_location can be linked in  without accompanying init code
   libc/2085: Re: libc/2085: Linux threads __errno_location can be linked in without accompanying init code





>Number:         2085
>Category:       libc
>Synopsis:       Linux threads __errno_location can be linked in without accompanying init code
>Confidential:   yes
>Severity:       serious
>Priority:       medium
>Responsible:    libc-gnats
>State:          open
>Quarter:        
>Keywords:       
>Class:          sw-bug
>Submitter-Id:   gnatsweb
>Arrival-Date:   Fri Feb 09 17:53:06 -0500 2001
>Cases:          
>Originator:     Kenneth C. Schalk
>Release:        2.1.3
>Organization:
Compaq Alpha Development Group
>Environment:
Alpha Linux RedHat 6.2

(I haven't tested this on other architectures.)
>Description:
If a program which doesn't make any pthreads calls is
linked against the Linux pthreads implementation, the
re-entrant version of __errno_location gets used, but the
corresponding initialization never takes place.  This
results in a seg fault on any attempt to access errno.

(Aparently this only happens when *statically* linking
against Linux pthreads.)

In this case we can't avoid linking against pthreads,
because we're working with a C++ library, some of which
uses threads.  We're compiling a collection of
applications which use this library.  We don't know
"a priori" whether each one uses any features of the
library which depend on pthreads, so we always include
it on the link line.

Currently we're working around this by telling the linker
to treat pthread_self as an undefined symbol
(-u pthread_self).  This causes the linker to pull in the
rest of the pthread library, including the initialization
code.
>How-To-Repeat:
Compile the simple source code which is attached with
either g++:

g++ -static errno_bug.C -lpthread

Or the Compaq Alpha Linux C++ compiler:

cxx -non_shared errno_bug.C -lpthread

Either way, the executable segfaults immediately.  Removing
the -lpthread reverts to the normal __errno_location, and
everything works fine.
>Fix:
Unknown
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="errno_bug.C"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="errno_bug.C"

I2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8ZXJybm8uaD4KCm1haW4oKQp7CiAgY291dCA8
PCAoKHZvaWQgKikgJmVycm5vKSA8PCBlbmRsOwp9Cg==
 






> I just compiled your program on an alpha running glibc 2.2 and had no
> problems:

> sigma:~/tmp:[0]$ g++ -Wall errno_bug.C -static
> errno_bug.C:5: warning: ISO C++ forbids declaration of `main' with no 
> type
> sigma:~/tmp:[0]$ ./a.out 
> 0x1200907a0

Please try using the exact compilation command I posted in my bug report.  
Without specifically asking for the pthreads library (passing "-lpthread" on 
the command line), the bug is not exhibited.

> The bug seems to be fixed now.

I don't agree.

There is a non-reentrant version of __errno_location in libc, which will be 
used unless you're linking with the pthread library.  The re-entrant version 
replaces the one in libc when libpthread is used.  It is only the version in 
libpthread that has the problem I reported.

--Ken








The following reply was made to PR libc/2085; it has been noted by GNATS.

From: Andreas Jaeger <aj@suse.de>
To: Kenneth Schalk <schalk@cadtls.hlo.dec.com>
Cc: bugs@gnu.org
Subject: Re: libc/2085: Linux threads __errno_location can be linked in  without accompanying init code
Date: 12 Feb 2001 18:49:25 +0100

 Kenneth Schalk <schalk@cadtls.hlo.dec.com> writes:
 
 > > I just compiled your program on an alpha running glibc 2.2 and had no
 > > problems:
 > 
 > > sigma:~/tmp:[0]$ g++ -Wall errno_bug.C -static
 > > errno_bug.C:5: warning: ISO C++ forbids declaration of `main' with no 
 > > type
 > > sigma:~/tmp:[0]$ ./a.out 
 > > 0x1200907a0
 > 
 > Please try using the exact compilation command I posted in my bug report.  
 
 Upps, that's a copy & paste error.  Thanks for reminding me.
 
 > Without specifically asking for the pthreads library (passing "-lpthread" on 
 > the command line), the bug is not exhibited.
 
 Ok, here're we're again:
 
 sigma:~/tmp:[0]$ g++ -Wall errno_bug.C -static -lpthread
 errno_bug.C:5: warning: ISO C++ forbids declaration of `main' with no 
 type
 sigma:~/tmp:[0]$ ./a.out 
 (nil)
 
 It's better than a segmentation fault - but still wrong :-(
 
 
 > > The bug seems to be fixed now.
 > 
 > I don't agree.
 
 Please note that this works fine on ia32, it seems to be a bug on
 alpha only.  I'll forward it to the main glibc mailing list.
 
 Andreas
 -- 
  Andreas Jaeger
   SuSE Labs aj@suse.de
    private aj@arthur.inka.de
     http://www.suse.de/~aj
 






The following reply was made to PR libc/2085; it has been noted by GNATS.

From: Andreas Jaeger <aj@suse.de>
To: kenneth.schalk@compaq.com
Cc: bugs@gnu.org
Subject: Re: libc/2085: Linux threads __errno_location can be linked in without accompanying init code
Date: 12 Feb 2001 11:01:47 +0100

 kenneth.schalk@compaq.com writes:
 
 > >Number:         2085
 > >Category:       libc
 > >Synopsis:       Linux threads __errno_location can be linked in without accompanying init code
 [...]
 > >Originator:     Kenneth C. Schalk
 > >Release:        2.1.3
 
 I just compiled your program on an alpha running glibc 2.2 and had no
 problems:
 
 sigma:~/tmp:[0]$ g++ -Wall errno_bug.C -static
 errno_bug.C:5: warning: ISO C++ forbids declaration of `main' with no 
 type
 sigma:~/tmp:[0]$ ./a.out 
 0x1200907a0
 
 The bug seems to be fixed now.
 
 Andreas
 -- 
  Andreas Jaeger
   SuSE Labs aj@suse.de
    private aj@arthur.inka.de
     http://www.suse.de/~aj
 





-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

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