| Summary: | Setting LD_PROFILE environment variable causes all executables to segmentation fault | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Shayan Pooya <shayan.pooya> | ||||
| Component: | glibc | Assignee: | Carlos O'Donell <codonell> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 18 | CC: | dushistov, fweimer, jakub, law, maxamillion, mnewsome, shayan.pooya, spoyarek, tsmetana | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2014-02-05 22:45:12 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
Not related to bash. AFAICT, this is occurring because the dynamic loader is allocating space for l_reloc_result *after* the call to ELF_DYNAMIC_RELOCATE. FWIW it doesn't happen on all binaries; it appears to be dependent upon what shared libraries a particular binary references. Meaning it's highly likely that referencing the unallocated l_reloc_result is dependent upon the set of dynamic relocations within the shared libraries referenced by the main program. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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 to click on "Clone This Bug" and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. This was fixed in Fedora 19 with the following upstream commit: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=2e64d2659d3edaebc792ac596a9863f1626e5c25 Do you need an F18 fix or can we close this? This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. 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 '18'. 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 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 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 18'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. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 567809 [details] Core dump when the application I run in step 3 is gdb Description of problem: In order to use sprof in my own project, I use the LD_PROFILE environment variable. However, there seems to a problem with this variable in the Fedora 16 that causes all of the executables (including the one I want to profile) to crash. Version-Release number of selected component (if applicable): It is in gnome-terminal version 3.2.1. I am not sure if this is a terminal-related problem. The system is an updated Fedora 16. The problem is not critical but it is certainly a bug. How reproducible: It is 100% reproducible on my system. Steps to Reproduce: 1. Open a gnome-terminal 2. Set LD_PROFILE: $ export LD_PROFILE="FOO" 3. Now run any executable (e.g. find, gdb, ...) and seg-fault. Actual results: Segmentation fault (Core dump) Expected results: Application running. Additional info: Attached is the core dump when I run gdb (version GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16)) The only way I can run the applications in this terminal now, is to unset LD_PROFILE. $ export LD_PROFILE="" Now I can run any executable. I run gdb over the core-dump: $ gdb /usr/bin/gdb /tmp/cores.18810: Output: ... Reading symbols from /usr/bin/gdb...(no debugging symbols found)...done. [New LWP 18810] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `gdb'. Program terminated with signal 11, Segmentation fault. #0 0x0000003c7820e723 in _dl_profile_fixup () from /lib64/ld-linux-x86-64.so.2 Missing separate debuginfos, use: debuginfo-install gdb-7.3.50.20110722-10.fc16. Backtrace: (gdb) bt #0 0x0000003c7820e723 in _dl_profile_fixup () from /lib64/ld-linux-x86-64.so.2 #1 0x0000003c782153a8 in _dl_runtime_profile () from /lib64/ld-linux-x86-64.so.2 #2 0x0000003c7961a9d5 in floor () from /lib64/libm.so.6 #3 0x0000003c7820bc74 in _dl_relocate_object () from /lib64/ld-linux-x86-64.so.2 #4 0x0000003c78203b2e in dl_main () from /lib64/ld-linux-x86-64.so.2 #5 0x0000003c782157f4 in _dl_sysdep_start () from /lib64/ld-linux-x86-64.so.2 #6 0x0000003c78205415 in _dl_start () from /lib64/ld-linux-x86-64.so.2 #7 0x0000003c782016e8 in _start () from /lib64/ld-linux-x86-64.so.2 #8 0x0000000000000001 in ?? () #9 0x00007fffe06d146e in ?? () #10 0x0000000000000000 in ?? ()