On my system the sysctl variable "kernel.core_pattern" is set such that all core dumps are collected in "/var/crash". Moreover the portage features "splitdebug" and "compressdebug" are enabled and CFLAGS includes "-ggdb". After each world update I have a huge bunch of core dumps in "/var/crash". The last time after I had run "emerge --update world" I found 742 individual core dumps with a sum of 1.7GB. It seems that "/lib64/ld-linux-x86-64 --verify" frequently crashes with signal 7. Expected result: no core dumps. However, every world update goes through successfully. It seems that it does not matter if "/lib64/ld-linux-x86-64 --verify" crashes. I have already found some reports that ld usually crashes if it is fed with garbage input files, i.e. files that are not valid ELF files. So it seems that these crashes do not affect the emerge process. Nonetheless I would prefer that "emerge --update world" does not fill my disk with core dumps.
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?