- Subject: libc/1171: 2.1.1 segfaults inside dynamic linker
- From: Various
- Date: Sun Jun 27 22:33:55 1999
Topics:
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Re: libc/1171: 2.1.1 segfaults inside dynamic linker
----------------------------------------------------------------------
Date: Sun, 27 Jun 1999 14:00:01 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271800.OAA24552@mescaline.gnu.org>
The following reply was made to PR libc/1171; it has been noted by GNATS.
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Date: 27 Jun 1999 19:58:11 +0200
>>>>> Craig Metz writes:
Craig> With LD_DEBUG=all, here's the last bit of it:
Craig> 00693: symbol=_IO_vfscanf; lookup in file=/usr/lib/libc.so.6
Craig> 00693: binding file /usr/lib/libc.so.6 to /usr/lib/libc.so.6: symbol `_IO_vfscanf' [GLIBC_2.0]
Craig> Segmentation fault
I thought you configured with --prefix=/usr ? In that case libc.so.6
should life in /lib and not in /usr/lib. It might be that you have an
old libc.so.6 in /usr/lib. Please double check that you're using the
right libc.so.6. You can execute libc.so.6 to see which version it is
- if it segfaults it glibc 2.0.x [1], otherwise you get exact version
information.
Andreas
Footnotes:
[1] The segfault is a bug, it should print some information as it
does with glibc 2.1.x.
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Sun, 27 Jun 1999 14:50:01 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271850.OAA27562@mescaline.gnu.org>
The following reply was made to PR libc/1171; it has been noted by GNATS.
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Date: 27 Jun 1999 20:43:47 +0200
>>>>> Craig Metz writes:
Craig> On my system, /lib is a symlink to /usr/lib, as is /usr/local/lib. It
Craig> prevents a whole class of problems.
I see. The output looks fine. Nothing unusual here. Strange.
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Sun, 27 Jun 1999 14:55:34 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271847.SAA18549@inner.net>
In message <u8so7d32n0.fsf@arthur.rhein-neckar.de>, you write:
>>>>>> Craig Metz writes:
>
>Craig> On my system, /lib is a symlink to /usr/lib, as is /usr/local/lib. It
>Craig> prevents a whole class of problems.
>I see. The output looks fine. Nothing unusual here. Strange.
I'm rebuilding glibc right now with those elf dynamic linker fixes, we'll see
if it fixes anything.
-Craig
------------------------------
Date: Sun, 27 Jun 1999 15:57:14 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271949.TAA18584@inner.net>
In message <u8n1xl30g3.fsf@arthur.rhein-neckar.de>, you write:
>Craig> glib, gdk, gtk, and imlib were rebuilt against 2.1.1. So only libXext
> and
>Craig> libX11 are not built against 2.1.1.
>Recompiling might help - but it should work nevertheless.
>
>If all this doesn't help, I'm at witts end:-(. In that case I'll
>forward our whole discussion to the glibc developers list, perhaps
>somebody else has a clue.
Those dynamic linker patches don't appear to have changed anything. Same
exact beahvior.
-Craig
------------------------------
Date: 27 Jun 1999 21:31:08 +0200
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-ID: <u8n1xl30g3.fsf@arthur.rhein-neckar.de>
References: <199906271846.SAA18544@inner.net>
>>>>> Craig Metz writes:
Craig> In message <u8vhc932pt.fsf@arthur.rhein-neckar.de>, you write:
Craig> I wonder if a lot of my problems would go away if I rebuilt my X libr
>> aries,
Craig> which were built against 2.0.x?
>> What kind of libraries are those programs linked against. I thought
>> you said libresolv was the problem? Can you send me an ldd output
>> from some programs?
Craig> Originally, a hello world program linked against libresolv wouldn't work,
Craig> which is clearly a bad bad thing. That seems to work now.
Strange. Either it should work always or it should fail always. I
don't understand this.
Craig> There are a few programs that never worked before and don't now, but they
Craig> did work briefly and I don't know what caused them to start working or to stop.
Craig> An example is gqmpeg:
Craig> libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40021000)
Craig> libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x4013a000)
Craig> libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4016c000)
Craig> libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4016f000)
Craig> libdl.so.2 => /usr/lib/libdl.so.2 (0x40192000)
Craig> libXext.so.6 => /usr/lib/libXext.so.6 (0x40195000)
Craig> libX11.so.6 => /usr/lib/libX11.so.6 (0x401a0000)
Craig> libm.so.6 => /usr/lib/libm.so.6 (0x40237000)
Craig> libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x40253000)
Craig> libc.so.6 => /usr/lib/libc.so.6 (0x40276000)
Craig> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Craig> glib, gdk, gtk, and imlib were rebuilt against 2.1.1. So only libXext and
Craig> libX11 are not built against 2.1.1.
Recompiling might help - but it should work nevertheless.
If all this doesn't help, I'm at witts end:-(. In that case I'll
forward our whole discussion to the glibc developers list, perhaps
somebody else has a clue.
Andreas
- -
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Sun, 27 Jun 1999 14:54:09 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271846.SAA18544@inner.net>
In message <u8vhc932pt.fsf@arthur.rhein-neckar.de>, you write:
>Craig> I wonder if a lot of my problems would go away if I rebuilt my X libr
>aries,
>Craig> which were built against 2.0.x?
>What kind of libraries are those programs linked against. I thought
>you said libresolv was the problem? Can you send me an ldd output
>from some programs?
Originally, a hello world program linked against libresolv wouldn't work,
which is clearly a bad bad thing. That seems to work now.
There are a few programs that never worked before and don't now, but they
did work briefly and I don't know what caused them to start working or to stop.
An example is gqmpeg:
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40021000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x4013a000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4016c000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4016f000)
libdl.so.2 => /usr/lib/libdl.so.2 (0x40192000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x40195000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x401a0000)
libm.so.6 => /usr/lib/libm.so.6 (0x40237000)
libgdk_imlib.so.1 => /usr/lib/libgdk_imlib.so.1 (0x40253000)
libc.so.6 => /usr/lib/libc.so.6 (0x40276000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
glib, gdk, gtk, and imlib were rebuilt against 2.1.1. So only libXext and
libX11 are not built against 2.1.1.
-Craig
------------------------------
Date: Sat, 19 Jun 1999 20:42:34 GMT
From: Craig Metz <cmetz@inner.net>
To: bugs@gnu.org
Subject: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906192042.UAA06928@inner.net>
>Number: 1171
>Category: libc
>Synopsis: 2.1.1 segfaults inside dynamic linker
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: libc-gnats
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Jun 19 16:50:01 EDT 1999
>Last-Modified:
>Originator: Craig Metz
>Organization:
<organization of PR author (multiple lines)>
>Release: libc-2.1.1
>Environment:
686, Linux 2.2.9, ELF
Host type: i686-pc-linux-gnu
System: Linux ministry-of-love 2.2.7 #10 Sat May 1 01:45:32 EDT 1999 i686 unknown
Architecture: i686
Addons: linuxthreads crypt
Build CC: gcc
Compiler version: egcs-2.91.66 19990314 (egcs-1.1.2 release)
Kernel headers: 2.2.10
Symbol versioning: yes
Build static: yes
Build shared: yes
Build pic-default: no
Build profile: yes
Build omitfp: no
Build bounded: no
Build static-nss: no
Stdio: libio
>Description:
After installing 2.1.1 built with configure options "--prefix=/usr --enable-add-ons=linuxthreads,crypt", several programs started to segfault immediately on execution. After some testing and some runs through gdb, I found that the segfaults were happenning well before main() gets called, and happen when some dynamic libraries are linked in.
The "-lresolv" linking in a dynamic library is what seems to trigger it to segfault on execution. There are many other dynamic libraries that will cause this to happen, but not all do. There does not seem to be any obvious pattern to which libraries work and which don't, and I have also found that the same library will sometimes cause this and sometimes not.
>How-To-Repeat:
int main(int argc, char **argv)
{
printf("foo\n");
}
gcc foo.c -o foo -lresolv
>Fix:
Oddly, even downgrading to 2.1 by removing all traces of 2.1.1's libraries and crt objects and letting ldconfig rebuild the symlinks doesn't fix this. I'm working on a reinstall now; it'd be nice btw if the 2.1 archive was on ftp.gnu.org.
>Audit-Trail:
>Unformatted:
------------------------------
Date: Sun, 20 Jun 1999 05:40:01 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906200940.FAA05790@mescaline.gnu.org>
The following reply was made to PR libc/1171; it has been noted by GNATS.
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Date: 20 Jun 1999 11:33:40 +0200
>>>>> Craig Metz writes:
>> Number: 1171
>> Category: libc
>> Synopsis: 2.1.1 segfaults inside dynamic linker
>> Description:
> After installing 2.1.1 built with configure options
> "--prefix=/usr --enable-add-ons=linuxthreads,crypt", several
> programs started to segfault immediately on execution. After some
> testing and some runs through gdb, I found that the segfaults
> were happenning well before main() gets called, and happen when
> some dynamic libraries are linked in. The "-lresolv" linking in
> a dynamic library is what seems to trigger it to segfault on
> execution. There are many other dynamic libraries that will cause
> this to happen, but not all do. There does not seem to be any
> obvious pattern to which libraries work and which don't, and I
> have also found that the same library will sometimes cause this
> and sometimes not.
>> How-To-Repeat:
> int main(int argc, char **argv)
> {
> printf("foo\n");
> }
> gcc foo.c -o foo -lresolv
>> Fix:
> Oddly, even downgrading to 2.1 by removing all traces of 2.1.1's
> libraries and crt objects and letting ldconfig rebuild the
> symlinks doesn't fix this. I'm working on a reinstall now; it'd
> be nice btw if the 2.1 archive was on ftp.gnu.org.
>> Audit-Trail:
>> Unformatted:
As you might expect I can't reproduce this here. I can give you only
some hints on checking what's broken:
- Are you linking against an old version of libresolv (perhaps a libc5
or glibc 2.0 one)? You might want to check with gcc -Wl,--verbose
which libraries are used.
- Since your small example didn't include any headers, this question
here is just for completeness: Do you use the right include files
(from glibc 2.1.1) ? Check it with e.g. gcc -E.
- You can check which libraries get used with LD_DEBUG, e.g.
LD_DEBUG=libs ./foo
It might be that the wrong libresolv is used at run time.
- Another problem might be your tools but egcs 1.1.2 should work.
Btw. glibc 2.1 is available at least from sourceware.cygnus.com and
ftp.funet.fi.
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Fri, 25 Jun 1999 16:10:01 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906252010.QAA03554@mescaline.gnu.org>
The following reply was made to PR libc/1171; it has been noted by GNATS.
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Date: 25 Jun 1999 22:01:47 +0200
>>>>> Craig Metz writes:
>> Number: 1171
>> Category: libc
>> Synopsis: 2.1.1 segfaults inside dynamic linker
Craig,
did you fix your problem? I still don't have a clue what might be
broken. The only so far reported and fixed bug in the dynamic linker
was a malloc overrun which only was detected with special malloc
checking tools:
1999-06-17 Andreas Jaeger <aj@arthur.rhein-neckar.de>
* elf/dl-load.c (_dl_init_paths): Add one more element to aelem
to not write beyond allocated memory.
Reported by John Reiser <jreiser@BitWagon.com>, closes PR libc/1167.
Andreas
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Sat, 26 Jun 1999 22:01:42 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906270154.BAA17939@inner.net>
In message <u89098cams.fsf@arthur.rhein-neckar.de>, you write:
>>>>>> Craig Metz writes:
>
>>> Number: 1171
>>> Category: libc
>>> Synopsis: 2.1.1 segfaults inside dynamic linker
>
>Craig,
>
>did you fix your problem? I still don't have a clue what might be
>broken. The only so far reported and fixed bug in the dynamic linker
>was a malloc overrun which only was detected with special malloc
>checking tools:
>
>1999-06-17 Andreas Jaeger <aj@arthur.rhein-neckar.de>
>
> * elf/dl-load.c (_dl_init_paths): Add one more element to aelem
> to not write beyond allocated memory.
> Reported by John Reiser <jreiser@BitWagon.com>, closes PR libc/1167.
>
>Andreas
I have not yet been able to figure out what causes this. There are only
certain apps that segfault, but they do so very very consistently, sort of.
After recompiling glibc many many times trying different options, suddenly it
all just started working. And it worked fine for a while. And a few days
later it wasn't working again. I have no idea why.
Can you send me the latest version of this particular file, and I'll see if
it makes things any better? Probably not, but worth a shot.
The bigger problem is that this is all happenning way before I can convince
gdb to grab control, so the otherwise obvious method for narrowing down where
this could be isn't an option.
-Craig
------------------------------
Date: Sun, 27 Jun 1999 07:00:02 -0400
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271100.HAA28131@mescaline.gnu.org>
The following reply was made to PR libc/1171; it has been noted by GNATS.
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Date: 27 Jun 1999 12:24:53 +0200
>>>>> Craig Metz writes:
Craig> I have not yet been able to figure out what causes this. There are only
Craig> certain apps that segfault, but they do so very very consistently, sort of.
Craig> After recompiling glibc many many times trying different options, suddenly it
Craig> all just started working. And it worked fine for a while. And a few days
Craig> later it wasn't working again. I have no idea why.
It could be a hardware problem or bugs in your tools.
Craig> Can you send me the latest version of this particular file, and I'll see if
Craig> it makes things any better? Probably not, but worth a shot.
I'm appending the two bugs we've fixed so far in the dynamic linker.
Craig> The bigger problem is that this is all happenning way before I can convince
Craig> gdb to grab control, so the otherwise obvious method for narrowing down where
Craig> this could be isn't an option.
Try the various options of LD_DEBUG (`LD_DEBUG=help ls' should give you
the help), this might be helpful.
Andreas
1999-06-17 Andreas Jaeger <aj@arthur.rhein-neckar.de>
* elf/dl-load.c (_dl_init_paths): Add one more element to aelem
to not write beyond allocated memory.
Reported by John Reiser <jreiser@BitWagon.com>, closes PR libc/1167.
1999-06-25 Andreas Schwab <schwab@issan.cs.uni-dortmund.de>
* elf/dl-deps.c (_dl_map_object_deps): When looking for the next
occurence of the aux object start with the current list entry, not
the new one. Adjust tail pointer in the unique list. Explain how
the meaning of the variables changes [PR libc/1168].
Index: elf/dl-load.c
===================================================================
RCS file: /cvs/glibc/libc/elf/dl-load.c,v
retrieving revision 1.103
retrieving revision 1.104
diff -u -r1.103 -r1.104
--- dl-load.c 1999/05/06 23:59:11 1.103
+++ dl-load.c 1999/06/17 09:35:56 1.104
@@ -513,7 +513,7 @@
/* First set up the rest of the default search directory entries. */
aelem = rtld_search_dirs = (struct r_search_path_elem **)
- malloc ((sizeof (system_dirs_len) / sizeof (system_dirs_len[0]))
+ malloc ((sizeof (system_dirs_len) / sizeof (system_dirs_len[0]) + 1)
* sizeof (struct r_search_path_elem *));
if (rtld_search_dirs == NULL)
_dl_signal_error (ENOMEM, NULL, "cannot create search path array");
Index: elf/dl-deps.c
===================================================================
RCS file: /cvs/glibc/libc/elf/dl-deps.c,v
retrieving revision 1.32
retrieving revision 1.32.2.1
diff -u -r1.32 -r1.32.2.1
--- dl-deps.c 1999/05/05 23:19:41 1.32
+++ dl-deps.c 1999/06/26 18:20:58 1.32.2.1
@@ -304,7 +304,10 @@
/* Allocate new entry. This always has to be done. */
newp = alloca (sizeof (struct list));
- /* Copy the content of the current entry over. */
+ /* We want to insert the new map before the current one,
+ but we have no back links. So we copy the contents of
+ the current entry over. Note that ORIG and NEWP now
+ have switched their meanings. */
orig->dup = memcpy (newp, orig, sizeof (*newp));
/* Initialize new entry. */
@@ -333,7 +336,7 @@
_dl_map_object. */
--args.aux->l_opencount;
- for (late = orig; late->unique; late = late->unique)
+ for (late = newp; late->unique; late = late->unique)
if (late->unique->map == args.aux)
break;
@@ -344,10 +347,13 @@
move it to this earlier position. */
orig->unique = newp;
- /* Now remove the later entry from the unique list. */
+ /* Now remove the later entry from the unique list
+ and adjust the tail pointer. */
+ if (utail == late->unique)
+ utail = late;
late->unique = late->unique->unique;
- /* We must move the earlier in the chain. */
+ /* We must move the object earlier in the chain. */
if (args.aux->l_prev)
args.aux->l_prev->l_next = args.aux->l_next;
if (args.aux->l_next)
--
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
Date: Sun, 27 Jun 1999 13:50:02 -0400
From: Craig Metz <cmetz@inner.net>
To: libc-gnats@gnu.org
Cc: gnats-admin@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271750.NAA23501@mescaline.gnu.org>
The following reply was made to PR libc/1171; it has been noted by GNATS.
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Date: Sun, 27 Jun 1999 13:47:35 -0400
In message <u84sju54ay.fsf@arthur.rhein-neckar.de>, you write:
>It could be a hardware problem or bugs in your tools.
My hardware isn't the problem; I've run with libc 5 and with glibc 2.0.6 and
2.1 on this hardware without any trouble.
I'm using egcs 1.1.2 and binutils 2.9.1; if there are more recent toolchains
that are more stable, I'm happy to try them. My build of glibc 2.1 I believe
was done with this exact same toolchain, and 2.0.6 was egcs 1.1.1 and an
earlier binutils if memory serves.
>I'm appending the two bugs we've fixed so far in the dynamic linker.
Ok, thanks. I'll give them a shot.
>Try the various options of LD_DEBUG (`LD_DEBUG=help ls' should give you
>the help), this might be helpful.
With LD_DEBUG=all, here's the last bit of it:
00693: symbol=_IO_vfscanf; lookup in file=/usr/lib/libc.so.6
00693: binding file /usr/lib/libc.so.6 to /usr/lib/libc.so.6: symbol `_IO_vfscanf' [GLIBC_2.0]
Segmentation fault
-Craig
------------------------------
Date: Sun, 27 Jun 1999 13:47:35 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271739.RAA18487@inner.net>
In message <u84sju54ay.fsf@arthur.rhein-neckar.de>, you write:
>It could be a hardware problem or bugs in your tools.
My hardware isn't the problem; I've run with libc 5 and with glibc 2.0.6 and
2.1 on this hardware without any trouble.
I'm using egcs 1.1.2 and binutils 2.9.1; if there are more recent toolchains
that are more stable, I'm happy to try them. My build of glibc 2.1 I believe
was done with this exact same toolchain, and 2.0.6 was egcs 1.1.1 and an
earlier binutils if memory serves.
>I'm appending the two bugs we've fixed so far in the dynamic linker.
Ok, thanks. I'll give them a shot.
>Try the various options of LD_DEBUG (`LD_DEBUG=help ls' should give you
>the help), this might be helpful.
With LD_DEBUG=all, here's the last bit of it:
00693: symbol=_IO_vfscanf; lookup in file=/usr/lib/libc.so.6
00693: binding file /usr/lib/libc.so.6 to /usr/lib/libc.so.6: symbol `_IO_vfscanf' [GLIBC_2.0]
Segmentation fault
-Craig
------------------------------
Date: Sun, 27 Jun 1999 14:15:48 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
cc: bugs@gnu.org
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271807.SAA18507@inner.net>
In message <u83dzd4jbg.fsf@arthur.rhein-neckar.de>, you write:
>>>>>> Craig Metz writes:
>Craig> With LD_DEBUG=all, here's the last bit of it:
>
>Craig> 00693: symbol=_IO_vfscanf; lookup in file=/usr/lib/libc.so.6
>Craig> 00693: binding file /usr/lib/libc.so.6 to /usr/lib/libc.so.6: symbol
>`_IO_vfscanf' [GLIBC_2.0]
>Craig> Segmentation fault
>
>I thought you configured with --prefix=/usr ? In that case libc.so.6
>should life in /lib and not in /usr/lib. It might be that you have an
>old libc.so.6 in /usr/lib. Please double check that you're using the
>right libc.so.6. You can execute libc.so.6 to see which version it is
>- if it segfaults it glibc 2.0.x [1], otherwise you get exact version
>information.
On my system, /lib is a symlink to /usr/lib, as is /usr/local/lib. It
prevents a whole class of problems.
It gives me:
GNU C Library stable release version 2.1.1, by Roland McGrath et al.
Copyright (C) 1992, 93, 94, 95, 96, 97, 98, 99 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version egcs-2.91.66 19990314 (egcs-1.1.2 release).
Compiled on a Linux 2.2.10 system on 1999-06-19.
Available extensions:
GNU libio by Per Bothner
linuxthreads-0.8 by Xavier Leroy
crypt add-on version 2.1 by Michael Glad and others
BIND-4.9.7-REL
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Report bugs using the `glibcbug' script to <bugs@gnu.org>.
-Craig
------------------------------
Date: Sun, 27 Jun 1999 14:19:28 -0400
From: Craig Metz <cmetz@inner.net>
To: Andreas Jaeger <aj@arthur.rhein-neckar.de>
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-Id: <199906271811.SAA18512@inner.net>
In message <u83dzd4jbg.fsf@arthur.rhein-neckar.de>, you write:
>I thought you configured with --prefix=/usr ? In that case libc.so.6
>should life in /lib and not in /usr/lib. It might be that you have an
>old libc.so.6 in /usr/lib. Please double check that you're using the
>right libc.so.6. You can execute libc.so.6 to see which version it is
>- if it segfaults it glibc 2.0.x [1], otherwise you get exact version
>information.
(this one is private, not to bugs@)
I wonder if a lot of my problems would go away if I rebuilt my X libraries,
which were built against 2.0.x?
A lot of people who know what they're talking about have commented privately
to me that they don't think the glibc symbol versioning stuff is going to work
in practice, that there are too many cases where if you throw enough libs into
the mixing pot it will snap. Maybe that's really what's happenning here?
-Craig
------------------------------
Date: 27 Jun 1999 20:42:06 +0200
From: Andreas Jaeger <aj@arthur.rhein-neckar.de>
To: Craig Metz <cmetz@inner.net>
Subject: Re: libc/1171: 2.1.1 segfaults inside dynamic linker
Message-ID: <u8vhc932pt.fsf@arthur.rhein-neckar.de>
References: <199906271811.SAA18512@inner.net>
>>>>> Craig Metz writes:
Craig> In message <u83dzd4jbg.fsf@arthur.rhein-neckar.de>, you write:
>> I thought you configured with --prefix=/usr ? In that case libc.so.6
>> should life in /lib and not in /usr/lib. It might be that you have an
>> old libc.so.6 in /usr/lib. Please double check that you're using the
>> right libc.so.6. You can execute libc.so.6 to see which version it is
>> - if it segfaults it glibc 2.0.x [1], otherwise you get exact version
>> information.
Craig> (this one is private, not to bugs@)
No problem.
Craig> I wonder if a lot of my problems would go away if I rebuilt my X libraries,
Craig> which were built against 2.0.x?
What kind of libraries are those programs linked against. I thought
you said libresolv was the problem? Can you send me an ldd output
from some programs?
Craig> A lot of people who know what they're talking about have commented privately
Craig> to me that they don't think the glibc symbol versioning stuff is going to work
Craig> in practice, that there are too many cases where if you throw enough libs into
Craig> the mixing pot it will snap. Maybe that's really what's happenning here?
The only problem is documented in the FAQ 2.27: libraries (not
binaries) using the stdio/libio interface needs to be recompiled since
it was impossible with versioning to solve a severe bug we've had to
fix. Other than that I haven't heard of any versioning problems on
the libc lists. The people you know didn't come up with a real
example, I guess.
Andreas
- -
Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de
for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de
------------------------------
End of forwardOTDXKe Digest
***************************