Bug 431777 - Programs using i386 nosegneg libraries segfault upon startup
Summary: Programs using i386 nosegneg libraries segfault upon startup
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-02-06 21:50 UTC by Lubomir Kundrak
Modified: 2008-02-07 10:18 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-02-07 10:18:44 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Lubomir Kundrak 2008-02-06 21:50:08 UTC
Version-Release number of selected component (if applicable):

glibc-2.7.90-6.i386

How reproducible:

Allways

Steps to Reproduce:
1. Install i386 glibc
2. LD_LIBRARY_PATH=/lib/i686/nosegneg /bin/cat
  
Actual results:

Segmentation fault

Additional info:

I could only reproduce this with i386 version and spot no problems with i686
one. This is fairly serious as  mkinitrd prefers these libraries and thus
produces unbootable images.

I did not attach backtrace as I was not sure if it would be helpful and this is
fairly easy to reproduce. Would it be of any use?

Comment 1 Jakub Jelinek 2008-02-07 08:52:08 UTC
glibc-2.7.90-6.i386.rpm (nor any other *.i386.rpm) doesn't include any
/lib/i686/nosegneg files.  Those are only in glibc-2*.i686.rpm.
If e.g. due to a failed rpm install you have both some older glibc-2*.i686.rpm
and a new glibc-2*.i386.rpm (why are you installing *.i386.rpm on i686 capable
box?), then mixing a new ld.so with old /lib/i686/nosegneg libraries of course
can and probably will crash badly.


Comment 2 Lubomir Kundrak 2008-02-07 10:18:44 UTC
I apologize -- I could have noticed that it doesn't make sense for a directory
named i686 to be in i386 package. Though I don't remember the rpm failing when
replacing i686 with i386 package, the directory is not owned by glibc.i386
package and so it's really not glibc's fault at all. (I was installing i386
libraries to construct image to run on via epia that can only run i586 tough it
identifies itself as i686). Closing.


Note You need to log in before you can comment on or make changes to this bug.