Bug 905034

Summary: [abrt] glibc-2.15-58.fc17: process_file: Process /usr/sbin/ldconfig was killed by signal 7 (SIGBUS)
Product: [Fedora] Fedora Reporter: Damian Wrobel <dwrobel>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: codonell, fweimer, jakub, law, pfrankli, schwab, spoyarek
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:0d6afdcb72536af1322f8aa01ab2dca57b5d1dda
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-09 13:47:55 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 Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status
none
File: smolt_data
none
File: var_log_messages none

Description Damian Wrobel 2013-01-28 12:26:29 UTC
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

Comment 1 Damian Wrobel 2013-01-28 12:26:32 UTC
Created attachment 688906 [details]
File: backtrace

Comment 2 Damian Wrobel 2013-01-28 12:26:35 UTC
Created attachment 688907 [details]
File: cgroup

Comment 3 Damian Wrobel 2013-01-28 12:26:38 UTC
Created attachment 688908 [details]
File: core_backtrace

Comment 4 Damian Wrobel 2013-01-28 12:26:40 UTC
Created attachment 688909 [details]
File: dso_list

Comment 5 Damian Wrobel 2013-01-28 12:26:43 UTC
Created attachment 688910 [details]
File: limits

Comment 6 Damian Wrobel 2013-01-28 12:26:45 UTC
Created attachment 688911 [details]
File: maps

Comment 7 Damian Wrobel 2013-01-28 12:26:48 UTC
Created attachment 688912 [details]
File: open_fds

Comment 8 Damian Wrobel 2013-01-28 12:26:51 UTC
Created attachment 688913 [details]
File: proc_pid_status

Comment 9 Damian Wrobel 2013-01-28 12:26:57 UTC
Created attachment 688914 [details]
File: smolt_data

Comment 10 Damian Wrobel 2013-01-28 12:27:00 UTC
Created attachment 688915 [details]
File: var_log_messages

Comment 11 Fedora Admin XMLRPC Client 2013-01-28 20:08:44 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 12 Fedora End Of Life 2013-07-03 21:17:03 UTC
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.

Comment 13 Carlos O'Donell 2013-07-09 13:47:55 UTC
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.

Comment 14 Carlos O'Donell 2013-07-10 16:01:27 UTC
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).

Comment 15 Damian Wrobel 2013-07-10 16:07:29 UTC
(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.

Comment 16 Carlos O'Donell 2013-07-10 16:18:08 UTC
(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.

Comment 17 Damian Wrobel 2013-07-10 19:37:07 UTC
(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.