Summary: | emerge triggers a lot crashes of "ld-linux-x86-64 --verify" with signal 7 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Matthias Nagel <matthias.nagel> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | slyfox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=601536 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info
Backtrace #1 Backtrace #2 |
Description
Matthias Nagel
2016-05-21 21:03:56 UTC
You should provide one of that crashes at least to let maintainers to review them Also your emerge --info output Sure, see attachments. Created attachment 435438 [details]
emerge --info
Created attachment 435446 [details]
Backtrace #1
Created attachment 435448 [details]
Backtrace #2
I have no idea what's up here. Maybe the toolchain guys will have an idea. ld-linux is the ldso from glibc, not the ld (linker) from binutils. please look in dmesg to see if there's any useful info. otherwise, load the crashes up in gdb and figure out what the full command line was that used for each one. dmesg is silent. How do I get the full command line? If I load the core file with gdb I get "Core was generated by `/lib64/ld-linux-x86-64.so.2 --verify /usr/lib64/debug/usr/lib64/samba/libauth4-'." during startup but this line is truncated. If I type "frame 6" in order to jump into the dl_main function followed by a "info local" I only get args = {str = 0x7fff02ec4884 "/usr/lib64/debug/usr/lib64/samba/libauth4-samba4.so.debug" ...} in return which seems incomplete, too. (At least the "--verify" part is missing.) (In reply to Matthias Nagel from comment #9) crashing on a debug file isn't surprising or necessarily even a bug. however, i wonder what is running that in the first place ... there's no value in running the ldso/--verify on split debug files. (In reply to SpanKY from comment #10) That is what I have already presumed in my comment #1. "ld-linux-x86-64 --verify" is known to crash if it is fed with malformed ELF binaries and I guess a split debug ELF belongs to this kind of file. You wonder why it is running in the first place. This is a wild guess: Maybe this is a long-standing bug in the ebuild system which has been unnoticed until now, because my setup is rather unusual. You must enable the "splitdebug" feature and the system must be configured to collect all core dumps in one place. If the latter is not true, then the core dump is generated in the working directory of the crashing process, i.e. the temporary build directory of the portage process and the build directory is deleted after the build has finished. Thus the core dump is deleted, too. Only in my case the core dump is not deleted, because it is stored outside of the portage tree. Anybody working on this? This is still an issue. As I noticed today "revdep-rebuild" causes a core dump of ld for each so-file on the system. revdep-rebuild misbehavior is being tracked in bug 601536. let's ignore that. there is no code in portage that runs `ld.so --verify`. setting kernel.core_pattern is not unusual. i do it all the time myself. my system isn't filling up with crash reports. even then, if core_pattern wasn't set, you'd still get the crash message in `dmesg` when it went badly, and people haven't been reporting that. you'll need to track down where that --verify call is coming from. find a small package to emerge that reproduces the crash (like pax-utils) and then dive from there. Matthias, do you still have then problem of crashes using revdep-rebuild or should we close the bug as obsolete? |