file on mips needs too much memory

Bug #7384 reported by Debian Bug Importer
12
Affects Status Importance Assigned to Milestone
file (Debian)
Fix Released
Unknown
file (Ubuntu)
Invalid
High
Unassigned

Bug Description

Automatically imported from Debian bug report #264920 http://bugs.debian.org/264920

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Automatically imported from Debian bug report #264920 http://bugs.debian.org/264920

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 11 Aug 2004 00:12:40 +0200
From: Matthias Klose <email address hidden>
To: <email address hidden>
Subject: file on mips needs too much memory

Package: file
Version: 4.10-3
Severity: serious

Noticed during gcc builds, that the calls to `file' during the gcc
build (i.e. calls to dh_strip) need too much memory, 'file' eating up to
1GB of RAM. I didn't see this behaviour on other architectures.

Revision history for this message
In , Michael Piefel (piefel) wrote : severity of 264920 is important

# Automatically generated email from bts, devscripts version 2.8
severity 264920 important

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 11 Aug 2004 12:30:23 +0200
From: Michael Piefel <email address hidden>
To: <email address hidden>
Subject: severity of 264920 is important

# Automatically generated email from bts, devscripts version 2.8
severity 264920 important

Revision history for this message
In , Martin Michlmayr (tbm) wrote :

* Matthias Klose <email address hidden> [2004-08-11 00:12]:
> Noticed during gcc builds, that the calls to `file' during the gcc
> build (i.e. calls to dh_strip) need too much memory, 'file' eating
> up to 1GB of RAM. I didn't see this behaviour on other
> architectures.

Did file change recently? Did you try with another version. Do you
still have that gcc binary so this bug can be reproduced?
--
Martin Michlmayr
<email address hidden>

Revision history for this message
In , Matthias Klose (doko-cs) wrote :

Martin Michlmayr writes:
> * Matthias Klose <email address hidden> [2004-08-11 00:12]:
> > Noticed during gcc builds, that the calls to `file' during the gcc
> > build (i.e. calls to dh_strip) need too much memory, 'file' eating
> > up to 1GB of RAM. I didn't see this behaviour on other
> > architectures.
>
> Did file change recently? Did you try with another version. Do you
> still have that gcc binary so this bug can be reproduced?

to reproduce on your host:

- su to doko
- chroot unstable ...
- cd gcc-3.3-3.3.4
- rm stamps/07* stamps/08*
- fakeroot debian/rules binary-arch

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 11 Aug 2004 13:25:10 +0100
From: Martin Michlmayr <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: Re: file on mips needs too much memory

* Matthias Klose <email address hidden> [2004-08-11 00:12]:
> Noticed during gcc builds, that the calls to `file' during the gcc
> build (i.e. calls to dh_strip) need too much memory, 'file' eating
> up to 1GB of RAM. I didn't see this behaviour on other
> architectures.

Did file change recently? Did you try with another version. Do you
still have that gcc binary so this bug can be reproduced?
--
Martin Michlmayr
<email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Wed, 11 Aug 2004 16:07:07 +0200
From: Matthias Klose <email address hidden>
To: Martin Michlmayr <email address hidden>
Cc: <email address hidden>
Subject: Re: file on mips needs too much memory

Martin Michlmayr writes:
> * Matthias Klose <email address hidden> [2004-08-11 00:12]:
> > Noticed during gcc builds, that the calls to `file' during the gcc
> > build (i.e. calls to dh_strip) need too much memory, 'file' eating
> > up to 1GB of RAM. I didn't see this behaviour on other
> > architectures.
>
> Did file change recently? Did you try with another version. Do you
> still have that gcc binary so this bug can be reproduced?

to reproduce on your host:

- su to doko
- chroot unstable ...
- cd gcc-3.3-3.3.4
- rm stamps/07* stamps/08*
- fakeroot debian/rules binary-arch

Revision history for this message
In , Martin Michlmayr (tbm) wrote :
Download full text (24.8 KiB)

* Matthias Klose <email address hidden> [2004-08-11 16:07]:
> > > Noticed during gcc builds, that the calls to `file' during the gcc
> > > build (i.e. calls to dh_strip) need too much memory, 'file' eating
> > > up to 1GB of RAM. I didn't see this behaviour on other
> > > architectures.
> >
> - fakeroot debian/rules binary-arch

If I'm not totally mistaken, this looks like a fakeroot problem to me.
I can run "file cpp-3.3" just fine, but "fakeroot file cpp-3.3"
segfaults (and works on i386). During "fakeroot debian/rules
binary-arch", dh_strip calls file which takes all memory. When I run
"debian/rules binary-arch" as root, it works.

I added "strace file" to dh_strip and get this when I run it with
fakeroot:

dh_strip -pcpp-3.3
execve("/usr/bin/file", ["file", "cpp-3.3"], [/* 19 vars */]) = 0
uname({sys="Linux", node="denial.cyrius.com", ...}) = 0
brk(0) = 0x10000290
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aac2000
open("/usr/lib/libfakeroot/libfakeroot.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\36"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=29676, ...}) = 0
old_mmap(NULL, 287760, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab02000
mprotect(0x2ab08000, 263184, PROT_NONE) = 0
old_mmap(0x2ab42000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab42000
close(3) = 0
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libfakeroot/libmagic.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libfakeroot/libmagic.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(0x7fff7160, 0x7fff7190) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=11527, ...}) = 0
old_mmap(NULL, 11527, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aac3000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libmagic.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\33"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=69404, ...}) = 0
old_mmap(NULL, 327600, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab49000
mprotect(0x2ab59000, 262064, PROT_NONE) = 0
old_mmap(0x2ab89000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab89000
close(3) = 0
open("/usr/lib/libfakeroot/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\025"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=81560, ...}) = 0
old_mmap(NULL, 339824, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab99000
mprotect(0x2abac000, 262000, PROT_NONE) = 0
old_mmap(0x2abeb000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x12000) = 0x2abeb000
close...

Revision history for this message
In , Clint Adams (clint) wrote :

> If I'm not totally mistaken, this looks like a fakeroot problem to me.
> I can run "file cpp-3.3" just fine, but "fakeroot file cpp-3.3"
> segfaults (and works on i386). During "fakeroot debian/rules

arch-specific fakeroot problems seem to mean that fakeroot is
exposing a kernel or libc bug.

What version of fakeroot?

Does it segfault under gdb (see instructions in
/usr/share/doc/fakeroot/DEBUG)? If so, is the backtrace useful?

> kill(24046, SIGTERM) = 0
> SYS_4246( <unfinished ... exit status 139>

What's 4246 on mips?

Revision history for this message
In , Martin Michlmayr (tbm) wrote :

* Clint Adams <email address hidden> [2004-08-12 13:33]:
> arch-specific fakeroot problems seem to mean that fakeroot is
> exposing a kernel or libc bug.

Hmm, it might be that the chroot is fucked. I just copied the binary
to another chroot and "fakeroot file" worked. Both are up-to-date
unstable chroots, though.
--
Martin Michlmayr
<email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (25.0 KiB)

Message-ID: <email address hidden>
Date: Thu, 12 Aug 2004 18:15:26 +0100
From: Martin Michlmayr <email address hidden>
To: Matthias Klose <email address hidden>
Cc: <email address hidden>, <email address hidden>
Subject: Re: file on mips needs too much memory

* Matthias Klose <email address hidden> [2004-08-11 16:07]:
> > > Noticed during gcc builds, that the calls to `file' during the gcc
> > > build (i.e. calls to dh_strip) need too much memory, 'file' eating
> > > up to 1GB of RAM. I didn't see this behaviour on other
> > > architectures.
> >
> - fakeroot debian/rules binary-arch

If I'm not totally mistaken, this looks like a fakeroot problem to me.
I can run "file cpp-3.3" just fine, but "fakeroot file cpp-3.3"
segfaults (and works on i386). During "fakeroot debian/rules
binary-arch", dh_strip calls file which takes all memory. When I run
"debian/rules binary-arch" as root, it works.

I added "strace file" to dh_strip and get this when I run it with
fakeroot:

dh_strip -pcpp-3.3
execve("/usr/bin/file", ["file", "cpp-3.3"], [/* 19 vars */]) = 0
uname({sys="Linux", node="denial.cyrius.com", ...}) = 0
brk(0) = 0x10000290
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aac2000
open("/usr/lib/libfakeroot/libfakeroot.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\36"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=29676, ...}) = 0
old_mmap(NULL, 287760, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab02000
mprotect(0x2ab08000, 263184, PROT_NONE) = 0
old_mmap(0x2ab42000, 28672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab42000
close(3) = 0
open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/libfakeroot/libmagic.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libfakeroot/libmagic.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64(0x7fff7160, 0x7fff7190) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=11527, ...}) = 0
old_mmap(NULL, 11527, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2aac3000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libmagic.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\33"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=69404, ...}) = 0
old_mmap(NULL, 327600, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2ab49000
mprotect(0x2ab59000, 262064, PROT_NONE) = 0
old_mmap(0x2ab89000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0x2ab89000
close(3) = 0
open("/usr/lib/libfakeroot/libz.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libz.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\10\0\0\0\1\0\0\025"..., 512) = 512
fstat64...

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 12 Aug 2004 13:33:27 -0400
From: Clint Adams <email address hidden>
To: Martin Michlmayr <email address hidden>
Cc: Matthias Klose <email address hidden>, <email address hidden>
Subject: Re: file on mips needs too much memory

> If I'm not totally mistaken, this looks like a fakeroot problem to me.
> I can run "file cpp-3.3" just fine, but "fakeroot file cpp-3.3"
> segfaults (and works on i386). During "fakeroot debian/rules

arch-specific fakeroot problems seem to mean that fakeroot is
exposing a kernel or libc bug.

What version of fakeroot?

Does it segfault under gdb (see instructions in
/usr/share/doc/fakeroot/DEBUG)? If so, is the backtrace useful?

> kill(24046, SIGTERM) = 0
> SYS_4246( <unfinished ... exit status 139>

What's 4246 on mips?

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 12 Aug 2004 18:48:18 +0100
From: Martin Michlmayr <email address hidden>
To: Clint Adams <email address hidden>
Cc: Matthias Klose <email address hidden>, <email address hidden>
Subject: Re: file on mips needs too much memory

* Clint Adams <email address hidden> [2004-08-12 13:33]:
> arch-specific fakeroot problems seem to mean that fakeroot is
> exposing a kernel or libc bug.

Hmm, it might be that the chroot is fucked. I just copied the binary
to another chroot and "fakeroot file" worked. Both are up-to-date
unstable chroots, though.
--
Martin Michlmayr
<email address hidden>

Revision history for this message
In , Matthias Klose (doko-cs) wrote :

Martin Michlmayr writes:
> * Clint Adams <email address hidden> [2004-08-12 13:33]:
> > arch-specific fakeroot problems seem to mean that fakeroot is
> > exposing a kernel or libc bug.
>
> Hmm, it might be that the chroot is fucked. I just copied the binary
> to another chroot and "fakeroot file" worked. Both are up-to-date
> unstable chroots, though.
> --
> Martin Michlmayr
> <email address hidden>

not reproducible in a fresh chroot.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Fri, 13 Aug 2004 11:41:10 +0200
From: Matthias Klose <email address hidden>
To: Martin Michlmayr <email address hidden>
Cc: Clint Adams <email address hidden>, <email address hidden>
Subject: Re: file on mips needs too much memory

Martin Michlmayr writes:
> * Clint Adams <email address hidden> [2004-08-12 13:33]:
> > arch-specific fakeroot problems seem to mean that fakeroot is
> > exposing a kernel or libc bug.
>
> Hmm, it might be that the chroot is fucked. I just copied the binary
> to another chroot and "fakeroot file" worked. Both are up-to-date
> unstable chroots, though.
> --
> Martin Michlmayr
> <email address hidden>

not reproducible in a fresh chroot.

Revision history for this message
In , Martin Michlmayr (tbm) wrote :

* Matthias Klose <email address hidden> [2004-08-13 11:41]:
> not reproducible in a fresh chroot.

Hmm, I just generated anoter chroot and see it... I'll check some
things, and maybe give Clint access if that would help.
--
Martin Michlmayr
<email address hidden>

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Fri, 13 Aug 2004 15:33:47 +0100
From: Martin Michlmayr <email address hidden>
To: Matthias Klose <email address hidden>
Cc: Clint Adams <email address hidden>, <email address hidden>
Subject: Re: file on mips needs too much memory

* Matthias Klose <email address hidden> [2004-08-13 11:41]:
> not reproducible in a fresh chroot.

Hmm, I just generated anoter chroot and see it... I'll check some
things, and maybe give Clint access if that would help.
--
Martin Michlmayr
<email address hidden>

Revision history for this message
Thom May (thombot) wrote :

We support NO STEEENKING MIPS HERE

Revision history for this message
In , Ben Burton (bab) wrote : More on file memory explosion

Hi. FWIW, I'm seeing this on a mips box that was freshly installed
yesterday (Aug 15). Package builds crash at the dh_strip stage because
/usr/bin/file is using up all 600M of memory+swap.

I'm not using a chroot at all (no disk space!). The memory explosion
only happens when running under fakeroot.

Using file 4.10-3, fakeroot 1.0.7, libc6 2.3.2.ds1-16.

Ben.

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Mon, 16 Aug 2004 16:55:47 +1000
From: Ben Burton <email address hidden>
To: <email address hidden>
Subject: More on file memory explosion

Hi. FWIW, I'm seeing this on a mips box that was freshly installed
yesterday (Aug 15). Package builds crash at the dh_strip stage because
/usr/bin/file is using up all 600M of memory+swap.

I'm not using a chroot at all (no disk space!). The memory explosion
only happens when running under fakeroot.

Using file 4.10-3, fakeroot 1.0.7, libc6 2.3.2.ds1-16.

Ben.

Revision history for this message
In , Frank Lichtenheld (djpig) wrote : reopening 264920

 # reproducible here, we really should figure this out
reopen 264920

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Wed, 25 Aug 2004 19:58:14 +0200
From: Frank Lichtenheld <email address hidden>
To: <email address hidden>
Subject: reopening 264920

 # reproducible here, we really should figure this out
reopen 264920

Revision history for this message
In , Adam Conrad (adconrad-trinitysoftware) wrote : file on mips needs too much memory -- me too!

I inadvertently downed casals the other day due to this same bug. It almost
happened again today, but I was babysitting my build from another SSH
session, due to paranoia, noticed file spinning out of control during
dh_strip, and killed it. Went hunting for bugs, and found this one.

I assume this is well-known already anyway, as the buildd on casals uses
"-rsudo" instead of "-rfakeroot".

... Adam

--
backup [n] (bak'up): The duplicate copy of crucial data that no one
                     bothered to make; used only in the abstract.

1024D/C6CEA0C9 C8B2 CB3E 3225 49BB 5ED2 0002 BE3C ED47 C6CE A0C9

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <004b01c49081$78587320$<email address hidden>>
Date: Thu, 2 Sep 2004 10:12:00 +1000
From: "Adam Conrad" <email address hidden>
To: <email address hidden>
Subject: file on mips needs too much memory -- me too!

I inadvertently downed casals the other day due to this same bug. It almost
happened again today, but I was babysitting my build from another SSH
session, due to paranoia, noticed file spinning out of control during
dh_strip, and killed it. Went hunting for bugs, and found this one.

I assume this is well-known already anyway, as the buildd on casals uses
"-rsudo" instead of "-rfakeroot".

... Adam

--
backup [n] (bak'up): The duplicate copy of crucial data that no one
                     bothered to make; used only in the abstract.

1024D/C6CEA0C9 C8B2 CB3E 3225 49BB 5ED2 0002 BE3C ED47 C6CE A0C9

Revision history for this message
In , Michael Piefel (piefel) wrote : tagging 264920

# Automatically generated email from bts, devscripts version 2.8.4
tags 264920 + help

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <email address hidden>
Date: Thu, 2 Sep 2004 12:12:17 +0200
From: Michael Piefel <email address hidden>
To: <email address hidden>
Subject: tagging 264920

# Automatically generated email from bts, devscripts version 2.8.4
tags 264920 + help

Revision history for this message
In , Martin Michlmayr (tbm) wrote : same bugs

reassign 264920 libc6
merge 264920 265678
--
Martin Michlmayr
http://www.cyrius.com/

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Thu, 7 Oct 2004 19:15:51 +0100
From: Martin Michlmayr <email address hidden>
To: <email address hidden>
Subject: same bugs

reassign 264920 libc6
merge 264920 265678
--
Martin Michlmayr
http://www.cyrius.com/

Revision history for this message
In , Thomas Hood (jdthood-aglu) wrote : severity serious

severity 265678 serious
thanks

This results in fakeroot being FTBFS on mips and mipsel (#279240).

--
Thomas Hood

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-Id: <1099648673.3654.430.camel@thanatos>
Date: Fri, 05 Nov 2004 10:57:54 +0100
From: Thomas Hood <email address hidden>
To: <email address hidden>
Subject: severity serious

severity 265678 serious
thanks

This results in fakeroot being FTBFS on mips and mipsel (#279240).

--
Thomas Hood

Revision history for this message
Debian Bug Importer (debzilla) wrote :

*** Bug 9932 has been marked as a duplicate of this bug. ***

Revision history for this message
In , GOTO Masanori (gotom-debian) wrote :

severity 265678 important
thanks

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 06 Nov 2004 18:22:19 +0900
From: GOTO Masanori <email address hidden>
To: <email address hidden>

severity 265678 important
thanks

Revision history for this message
In , Thiemo Seufer (ths-networkno) wrote : Fix/Workaround for broken symbol resolving on mips/mipsel
Download full text (4.6 KiB)

tags 265678 +patch
thanks

ld.so for mips/mipsel resolves symbols to the lazy evaluation stub of
in between libraries. The stubs aren't marked by anything beyond the
section information, but their symbols are SHN_UNDEF.

The appended patch works around this by ignoring SHN_UNDEF symbols in
the resolver lookup function. It may break copy relocations on other
architectures, so it should be mips specific. It also includes a
INTUSE cleanup which is unrelated to this bug.

I built and installed the resulting libc on several mips machines,
fakeroot works, no ill effects observed so far.

Thiemo

#! /bin/sh -e

# All lines beginning with `# DP:' are a description of the patch.
# DP: Description: Workaround invalid resolving of lazy evaluation stubs
# DP: Author: Thiemo Seufer <email address hidden>
# DP: Date: 2005-04-11

if [ $# -ne 2 ]; then
    echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
    exit 1
fi
case "$1" in
    -patch) patch -d "$2" -f --no-backup-if-mismatch -p2 < $0;;
    -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p2 < $0;;
    *)
 echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
 exit 1
esac
exit 0

# append the patch here and adjust the -p? flag in the patch calls.
diff -upr build-tree.orig/glibc-2.3.2/elf/do-lookup.h build-tree/glibc-2.3.2/elf/do-lookup.h
--- build-tree.orig/glibc-2.3.2/elf/do-lookup.h 2005-02-28 23:42:31.000000000 +0100
+++ build-tree/glibc-2.3.2/elf/do-lookup.h 2005-04-11 18:19:20.000000000 +0200
@@ -209,6 +209,11 @@ FCT (const char *undef_name, unsigned lo
   }
        /* FALLTHROUGH */
      case STB_GLOBAL:
+ /* HACK: MIPS marks its lazy evaluation stubs with SHN_UNDEF
+ symbols, we skip them. */
+ if (sym->st_shndx == SHN_UNDEF)
+ break;
+
        /* Global definition. Just what we need. */
        result->s = sym;
        result->m = map;
diff -upr build-tree.orig/glibc-2.3.2/sysdeps/mips/dl-machine.h build-tree/glibc-2.3.2/sysdeps/mips/dl-machine.h
--- build-tree.orig/glibc-2.3.2/sysdeps/mips/dl-machine.h 2005-02-28 23:42:36.000000000 +0100
+++ build-tree/glibc-2.3.2/sysdeps/mips/dl-machine.h 2005-04-10 22:39:15.000000000 +0200
@@ -347,5 +347,6 @@ __dl_runtime_resolve (ElfW(Word) sym_ind
   const ElfW(Word) gotsym \
     = (const ElfW(Word)) l->l_info[DT_MIPS (GOTSYM)]->d_un.d_val; \
   const ElfW(Sym) *sym = &symtab[sym_index]; \
+ lookup_t result; \
   ElfW(Addr) value; \
                \
@@ -363,30 +364,37 @@ __dl_runtime_resolve (ElfW(Word) sym_ind
                \
      if (version->hash != 0) \
        { \
- value = _dl_lookup_versioned_symbol(strtab + sym->st_name, l, \
- &sym, l->l_scope, version,\
- ELF_RTYPE_CLASS_PLT, 0); \
+ result = INTUSE(_dl_lookup_versioned_symbol) (strtab \
+ + sym->st_name, \
+ l, &sym, \
+ l->l_scope, \
+ version, \
+ ELF_RTYPE_CLASS_PLT,\
+ 0);\
   break; \
        } \
      /* Fall through. */ \
    } \
  case 0: \
- value = _dl_lookup_symbol (strtab + ...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (4.8 KiB)

Message-ID: <email address hidden>
Date: Wed, 13 Apr 2005 03:17:02 +0200
From: Thiemo Seufer <email address hidden>
To: <email address hidden>
Subject: Fix/Workaround for broken symbol resolving on mips/mipsel

tags 265678 +patch
thanks

ld.so for mips/mipsel resolves symbols to the lazy evaluation stub of
in between libraries. The stubs aren't marked by anything beyond the
section information, but their symbols are SHN_UNDEF.

The appended patch works around this by ignoring SHN_UNDEF symbols in
the resolver lookup function. It may break copy relocations on other
architectures, so it should be mips specific. It also includes a
INTUSE cleanup which is unrelated to this bug.

I built and installed the resulting libc on several mips machines,
fakeroot works, no ill effects observed so far.

Thiemo

#! /bin/sh -e

# All lines beginning with `# DP:' are a description of the patch.
# DP: Description: Workaround invalid resolving of lazy evaluation stubs
# DP: Author: Thiemo Seufer <email address hidden>
# DP: Date: 2005-04-11

if [ $# -ne 2 ]; then
    echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
    exit 1
fi
case "$1" in
    -patch) patch -d "$2" -f --no-backup-if-mismatch -p2 < $0;;
    -unpatch) patch -d "$2" -f --no-backup-if-mismatch -R -p2 < $0;;
    *)
 echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
 exit 1
esac
exit 0

# append the patch here and adjust the -p? flag in the patch calls.
diff -upr build-tree.orig/glibc-2.3.2/elf/do-lookup.h build-tree/glibc-2.3.2/elf/do-lookup.h
--- build-tree.orig/glibc-2.3.2/elf/do-lookup.h 2005-02-28 23:42:31.000000000 +0100
+++ build-tree/glibc-2.3.2/elf/do-lookup.h 2005-04-11 18:19:20.000000000 +0200
@@ -209,6 +209,11 @@ FCT (const char *undef_name, unsigned lo
   }
        /* FALLTHROUGH */
      case STB_GLOBAL:
+ /* HACK: MIPS marks its lazy evaluation stubs with SHN_UNDEF
+ symbols, we skip them. */
+ if (sym->st_shndx == SHN_UNDEF)
+ break;
+
        /* Global definition. Just what we need. */
        result->s = sym;
        result->m = map;
diff -upr build-tree.orig/glibc-2.3.2/sysdeps/mips/dl-machine.h build-tree/glibc-2.3.2/sysdeps/mips/dl-machine.h
--- build-tree.orig/glibc-2.3.2/sysdeps/mips/dl-machine.h 2005-02-28 23:42:36.000000000 +0100
+++ build-tree/glibc-2.3.2/sysdeps/mips/dl-machine.h 2005-04-10 22:39:15.000000000 +0200
@@ -347,5 +347,6 @@ __dl_runtime_resolve (ElfW(Word) sym_ind
   const ElfW(Word) gotsym \
     = (const ElfW(Word)) l->l_info[DT_MIPS (GOTSYM)]->d_un.d_val; \
   const ElfW(Sym) *sym = &symtab[sym_index]; \
+ lookup_t result; \
   ElfW(Addr) value; \
                \
@@ -363,30 +364,37 @@ __dl_runtime_resolve (ElfW(Word) sym_ind
                \
      if (version->hash != 0) \
        { \
- value = _dl_lookup_versioned_symbol(strtab + sym->st_name, l, \
- &sym, l->l_scope, version,\
- ELF_RTYPE_CLASS_PLT, 0); \
+ result = INTUSE(_dl_lookup_versioned_symbol) (strtab \
+ + sym->st_name, \
+ l, &sym, \
+ l->l_scope, \
+ version, \
+ ...

Read more...

Revision history for this message
In , GOTO Masanori (gotom) wrote : Bug#264920: fixed in glibc 2.3.2.ds1-21
Download full text (7.5 KiB)

Source: glibc
Source-Version: 2.3.2.ds1-21

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.2.ds1-21_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.2.ds1-21_all.deb
glibc_2.3.2.ds1-21.diff.gz
  to pool/main/g/glibc/glibc_2.3.2.ds1-21.diff.gz
glibc_2.3.2.ds1-21.dsc
  to pool/main/g/glibc/glibc_2.3.2.ds1-21.dsc
libc6-dbg_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.2.ds1-21_i386.deb
libc6-dev_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.2.ds1-21_i386.deb
libc6-i686_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.2.ds1-21_i386.deb
libc6-pic_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.2.ds1-21_i386.deb
libc6-prof_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.2.ds1-21_i386.deb
libc6-udeb_2.3.2.ds1-21_i386.udeb
  to pool/main/g/glibc/libc6-udeb_2.3.2.ds1-21_i386.udeb
libc6_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6_2.3.2.ds1-21_i386.deb
libnss-dns-udeb_2.3.2.ds1-21_i386.udeb
  to pool/main/g/glibc/libnss-dns-udeb_2.3.2.ds1-21_i386.udeb
libnss-files-udeb_2.3.2.ds1-21_i386.udeb
  to pool/main/g/glibc/libnss-files-udeb_2.3.2.ds1-21_i386.udeb
locales_2.3.2.ds1-21_all.deb
  to pool/main/g/glibc/locales_2.3.2.ds1-21_all.deb
nscd_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/nscd_2.3.2.ds1-21_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
GOTO Masanori <email address hidden> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 14 Feb 2005 09:26:26 +0900
Source: glibc
Binary: libc6-i686 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.2.ds1-21
Distribution: unstable
Urgency: high
Maintainer: GOTO Masanori <email address hidden>
Changed-By: GOTO Masanori <email address hidden>
Description:
 glibc-doc - GNU C Library: Documentation
 libc6 - GNU C Library: Shared libraries and Timezone data
 libc6-dbg - GNU C Library: Libraries with debugging symbols
 libc6-dev - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-pic - GNU C Library: PIC archive library
 libc6-prof - GNU C Library: Profiling Libraries
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS...

Read more...

Revision history for this message
Debian Bug Importer (debzilla) wrote :
Download full text (7.7 KiB)

Message-Id: <email address hidden>
Date: Sat, 16 Apr 2005 09:17:24 -0400
From: GOTO Masanori <email address hidden>
To: <email address hidden>
Subject: Bug#264920: fixed in glibc 2.3.2.ds1-21

Source: glibc
Source-Version: 2.3.2.ds1-21

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive:

glibc-doc_2.3.2.ds1-21_all.deb
  to pool/main/g/glibc/glibc-doc_2.3.2.ds1-21_all.deb
glibc_2.3.2.ds1-21.diff.gz
  to pool/main/g/glibc/glibc_2.3.2.ds1-21.diff.gz
glibc_2.3.2.ds1-21.dsc
  to pool/main/g/glibc/glibc_2.3.2.ds1-21.dsc
libc6-dbg_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-dbg_2.3.2.ds1-21_i386.deb
libc6-dev_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-dev_2.3.2.ds1-21_i386.deb
libc6-i686_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-i686_2.3.2.ds1-21_i386.deb
libc6-pic_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-pic_2.3.2.ds1-21_i386.deb
libc6-prof_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6-prof_2.3.2.ds1-21_i386.deb
libc6-udeb_2.3.2.ds1-21_i386.udeb
  to pool/main/g/glibc/libc6-udeb_2.3.2.ds1-21_i386.udeb
libc6_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/libc6_2.3.2.ds1-21_i386.deb
libnss-dns-udeb_2.3.2.ds1-21_i386.udeb
  to pool/main/g/glibc/libnss-dns-udeb_2.3.2.ds1-21_i386.udeb
libnss-files-udeb_2.3.2.ds1-21_i386.udeb
  to pool/main/g/glibc/libnss-files-udeb_2.3.2.ds1-21_i386.udeb
locales_2.3.2.ds1-21_all.deb
  to pool/main/g/glibc/locales_2.3.2.ds1-21_all.deb
nscd_2.3.2.ds1-21_i386.deb
  to pool/main/g/glibc/nscd_2.3.2.ds1-21_i386.deb

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to <email address hidden>,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
GOTO Masanori <email address hidden> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing <email address hidden>)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Mon, 14 Feb 2005 09:26:26 +0900
Source: glibc
Binary: libc6-i686 libc0.3-pic glibc-doc libc1-udeb libc0.3 libc6.1-dev libc1-pic libc6-s390x libnss-files-udeb libc1-dbg libc6-dev-sparc64 libc0.3-dev libc6-udeb libc6-dbg libc6.1-pic libc6-dev libc0.3-prof libc6-sparcv9 libc6.1-prof libc1 locales libc6-pic libc0.3-udeb libc1-prof libc0.3-dbg libc6-prof libc6 libc6-sparcv9b libc6.1-udeb libc6.1-dbg nscd libc6-sparc64 libnss-dns-udeb libc6.1 libc1-dev libc6-dev-s390x
Architecture: source i386 all
Version: 2.3.2.ds1-21
Distribution: unstable
Urgency: high
Maintainer: GOTO Masanori <email address hidden>
Changed-By: GOTO Masanori <email address hidden>
Description:
 glibc-doc - GNU C Library: Documentation
 libc6 - GNU C Library: Shared libraries and Timezone data
 libc6-dbg - GNU C Library: Libraries with debugging symbols
 libc6-dev - GNU C Library: Development Libraries and Header Files
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]...

Read more...

Changed in file:
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.