Description of problem: Compiling 3rd party software. Version-Release number of selected component: glibc-2.15-58.fc17 Additional info: backtrace_rating: 4 crash_function: process_file environ: _=/usr/sbin/ldconfig executable: /usr/sbin/ldconfig kernel: 3.7.4-104.fc17.x86_64 remote_result: NOTFOUND uid: 1000 Truncated backtrace: Thread no. 1 (3 frames) #0 process_file at readlib.c:131 #1 search_dir at ldconfig.c:872 #2 search_dirs at ldconfig.c:1023
Created attachment 688906 [details] File: backtrace
Created attachment 688907 [details] File: cgroup
Created attachment 688908 [details] File: core_backtrace
Created attachment 688909 [details] File: dso_list
Created attachment 688910 [details] File: limits
Created attachment 688911 [details] File: maps
Created attachment 688912 [details] File: open_fds
Created attachment 688913 [details] File: proc_pid_status
Created attachment 688914 [details] File: smolt_data
Created attachment 688915 [details] File: var_log_messages
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Marking closed because of insufficient data. If you can reproduce this and it happens again please run the exact ldconfig command again with `-v' to determine which file caused ldconfig to SIGBUS. The most likely problem is that there is an invalid library on the search path, either corrupted, or built incorrectly by another tools. The reason I say this is that the particular failure point in ldconfig would only fail if the library was invalid. The more complex hypothesis is that ldconfig was incorrectly compiled, but that would have resulted in many more reports like this and we only have this one.
A closer look at the logs reveals it was processing a MIPS shared library from what appears to be a BCM7231 embedded build here /home/D.Wrobel/projects/mhp/head/blackhole/.bcm7231/pil_packages/p-broadcomnexus-bcm7231b0/staging_dir/usr/lib/libjpeg.so. The format of that library would likely result in a SIGBUGS for ldconfig since we don't support alternate architectures. I'm marking this as CLOSED NOTABUG since it's outside what ldconfig is expected to do. Please file an upstream bug to add support for ignoring shared libraries from non-native targets (much harder than you think given multiarch, bi-arch, and emulated support).
(In reply to Carlos O'Donell from comment #14) >I'm marking this as CLOSED NOTABUG since it's outside what ldconfig is expected to do. I'm not expected that ldconfig should support it but it would be appreciated if it wouldn't crash accidentally just because it faced some different binary blob.
(In reply to Damian Wrobel from comment #15) > (In reply to Carlos O'Donell from comment #14) > >I'm marking this as CLOSED NOTABUG since it's outside what ldconfig is expected to do. > > I'm not expected that ldconfig should support it but it would be appreciated > if it wouldn't crash accidentally just because it faced some different > binary blob. I don't disagree, but that's a decision that upstream has to make. There would need to be a lot of defensive coding to support preventing ldconfig from crashing on arbitrary binary blobs.
(In reply to Carlos O'Donell from comment #16) > (In reply to Damian Wrobel from comment #15) > > (In reply to Carlos O'Donell from comment #14) > I don't disagree, but that's a decision that upstream has to make. Thanks for clarification, as of now I don't observe this crashes if it will be reproducible I'll consider to report it upstream.