Bug 1184234
| Summary: | apparent glibc bug causes gnucash to segfault on startup when LD_LIBRARY_PATH is set to nonexistent directory | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Steve Holland <sh1> | ||||
| Component: | glibc | Assignee: | Siddhesh Poyarekar <spoyarek> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 21 | CC: | arjun.is, codonell, fweimer, jakub, law, lnewman, mnewsome, notting, pfrankli, spoyarek | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | glibc-2.20-8.fc21 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-03-04 10:26:42 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1443236 | ||||||
| Attachments: |
|
||||||
The core C library is linked into every application and therefore involved in most strack traces. In order to effectively triage the incoming requests we need the help of users and developers alike to determine root causes. Would you please provde an SOS report, or run gnucash through the debugger to produce a backtrace that can help us sort this bug against other bugs, and suggest a workaround or solution? As it is this bug does not contain enough information for me to conclude that it's a problem with glibc. Please reopen when you have an SOS report or backtrace with symbol information. Until then I'm going to move this bug to gnucash for the gnucach maintainers to investigate. Created attachment 982161 [details]
Stack backtrace from gdb
stack backtrace attached; Frame #11 is where it enters the C library, trying to open /usr/lib64/gio/modules/libgvfsdbus.so
This is a glibc bug. Allan had posted a patch[1] for it for which I had asked for a test case. I'll see if I can write one myself and have this fixed. [1] https://sourceware.org/ml/libc-alpha/2014-10/msg00328.html *** Bug 1187980 has been marked as a duplicate of this bug. *** glibc-2.20-8.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/glibc-2.20-8.fc21 Package glibc-2.20-8.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing glibc-2.20-8.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-2837/glibc-2.20-8.fc21 then log in and leave karma (feedback). glibc-2.20-8.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: An apparent glibc bug causes gnucash to segfault on startup when LD_LIBRARY_PATH is set to a nonexistant directory Version-Release number of selected component (if applicable): gnucash-2.6.4-1.fc21.x86_64 glibc-2.20-7.fc21.x86_64 glib2-2.42.1-1.fc21.x86_64 gvfs-1.22.3-1.fc21.x86_64 How reproducible: Always Steps to Reproduce: 1. export LD_LIBRARY_PATH=/nonexistent_path 2. gnucash & 3. watch gnucash segfault Actual results: Segmentation fault Expected results: gnucash starts successfully. Clearing LD_LIBRARY_PATH, or pointing LD_LIBRARY_PATH at a directory which actually exists, resolves the problem. Additional info: The segmentation fault seems to occur when glib's _g_module_open() calls dlopen() at gmodule-dl.c:97 The filename to be opened is /usr/lib64/gio/modules/libgvfsdbus.so -- part of gvfs2. dlopen() is given an absolute path, so it should not be searching per the man page: "If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname. Otherwise, the dynamic linker searches for the library ... " (Since filename contains a slash, the otherwise clause is not applicable, so dlopen() should not be searching) dlopen seems to be searching through LD_LIBRARY_PATH anyway (based on strace output) and a segmentation fault occurs several function calls deep. Clearing LD_LIBRARY_PATH resolves the problem This might be the root cause of bug #1177891