Bug 136027
Summary: | Static linked binaries are seg faulting | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Brian Bruns <bruns> | ||||
Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||
Status: | CLOSED NOTABUG | QA Contact: | |||||
Severity: | high | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | rawhide | CC: | barryn, riel, roland, sopwith | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2004-10-18 09:51:53 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Brian Bruns
2004-10-16 22:18:54 UTC
While this bug doesn't make much sense (and the filer has admitted it on irc) , it's filed by somebody whose observation skills I tend to trust. Wonder if it's got anything to do with prelink and/or non-PIE binaries breaking, or something else getting in the way ? If FC3's current libc somehow breaks statically linked binaries from 3rd parties, this might be a showstopper. OK, the gdb output I got on irc makes a little more sense. Looks like the static binary he has tries to load the vsyscall page ... <Bruns> Reading symbols from shared object read from target memory...(no debugging symbols found)...done. <Bruns> Loaded system supplied DSO at 0xffffe000 <Bruns> Program received signal SIGSEGV, Segmentation fault. <Bruns> 0x00000000 in ?? () No debugging symbols so no backtrace ... but the DSO looks obvious. <Bruns> this is a stock 2.6.8.1 kernel ok, another crucial data point... Created attachment 105334 [details]
static compiled bash which is seg faulting
This is one of the multiple static binaries on the system which seg fault when
the glibc is updated. I can attach more if necessary
Old static binaries that may use NSS (which bash can, e.g. for ~user lookups) are not guaranteed to work unless you supply them with the exact libnss* DSOs from the glibc version originally linked with. If this is the only problem, this is not something we will change. If there is a problem with freshly made static binaries, or static binaries that do not use any dynamic modules at all, then we can look into it. But that would need a recipe to make such a binary from source. We cannot just use unknown binaries you give us. Sounds like an item for the release notes - though admittedly I don't know enough about glibc to tell for sure... Roland, if this indeed a release note worthy item, would you mind writing up a paragraph or so for the FC3 release notes ? ;) This is not a new or one-time issue. It is a specified limitation of using static linking with glibc. It should already be documented somewhere, since it's been true of static linking with glibc since 2.0. Furthermore, when linking such statically linked applications, linker already warns about this, e.g.: warning: Using 'getgrnam' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking I'll note that the breakage is gone with glibc-2.3.3-73, and the static binaries that were seg faulting are now running fine again. |