| Summary: | sys-libs/glibc-2.19: upgrade resulted in sigsegv on almost any program executed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Honza <hkmaly> |
| Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | tdalman |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Log from removing glibc-2.16 with the segfaults
Log from installing glibc-2.19 Dumped core from running LD_PRELOAD=/lib/libc-2.19.so /lib/ld-2.19.so /bin/ls -lisa Log from successfull installation of glibc-2.19 |
||
|
Description
Honza
2015-03-15 02:59:33 UTC
Created attachment 398952 [details]
Log from removing glibc-2.16 with the segfaults
Log from removing glibc-2.16 with the segfaults
Created attachment 398954 [details]
Log from installing glibc-2.19
Log from installing glibc-2.19 ... I see the segfaults are here as well.
Created attachment 399334 [details] Dumped core from running LD_PRELOAD=/lib/libc-2.19.so /lib/ld-2.19.so /bin/ls -lisa The core produced when I run LD_PRELOAD=/lib/libc-2.19.so /lib/ld-2.19.so /bin/ls -lisa It's interesting that ls without arguments run without segfault and ls with arguments segfaults. ... not sure if it's good for something, but I have no idea what other informations may be needed. I'm not able to say where the segfault occured because as I said, gdb is segfaulting as well ... if there are some options how to discover it from this core file or using some different method I'm not aware of them. I've found https://forums.gentoo.org/viewtopic-t-982658-highlight-glibc.html but they claim that glibc-2.19 SOLVED their problem ... Ok ... tried some blind updates: installing sys-kernel/linux-headers-3.13, switching binutils to i686-pc-linux-gnu-2.23.2 and emerging glibc 2.19 again apparently helped, no segfaults with that one yet. Created attachment 399336 [details]
Log from successfull installation of glibc-2.19
Log from successfull installation of glibc-2.19, for comparison. Interesting differences:
checking whether to use .ctors/.dtors header and trailer... no
checking linker output format... elf32-i386
... of course, might not be related.
When reporting segfaults you should provide a meaningful backtrace as described here: http://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces Core dump itself is almost useless without exact binary caused it, especially when program was compiled without debugging and was stripped. my guess is that it was due to your old version of binutils -- 2.20 is more than 4 years old. newer versions of glibc already force an upgrade to 2.24. so if things are working for you now, i'd say that's that Andrew Savchenko: The instruction from producing backtrace are useless or at least not enough for debugging glibc. As I said, gdb itself was segfaulting, and newer glibc was not running without new dynamic linker ... but sorry about debugging symbols. I've should post the core after compiling the glibc with splitdebug or something. SpanKY: 4 years already? .... If you think so, you should resolve this bug by changing the DEPEND to higher version and not by WONTFIX. Or are you waiting for another user having same problem before that? On the other hand, 2.24 apparently wasn't needed. PS: Technically it was glibc-2.19-r1 I was trying. Forgot to add that -r1. Although I doubt that made difference. (In reply to Honza from comment #8) glibc-2.20 is already in the pipeline for stabilization and requires newer binutils. considering you're the first to hit this, i'm not worried about it being a wider problem. unless the problem is triaged deeper and shown it is actually an issue with old binutils, i don't want to change the code. considering you updated to a current stable system and things are working fine, it doesn't sound like it's worth the time to track this down. |
