Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 583724 - emerge triggers a lot crashes of "ld-linux-x86-64 --verify" with signal 7
Summary: emerge triggers a lot crashes of "ld-linux-x86-64 --verify" with signal 7
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-05-21 21:03 UTC by Matthias Nagel
Modified: 2019-01-27 12:04 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge-info.txt,6.81 KB, text/plain)
2016-05-26 08:34 UTC, Matthias Nagel
Details
Backtrace #1 (backtrace-ld-1462724618.txt,2.80 KB, text/plain)
2016-05-26 08:44 UTC, Matthias Nagel
Details
Backtrace #2 (backtrace-ld-1462724638.txt,2.75 KB, text/plain)
2016-05-26 08:45 UTC, Matthias Nagel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Nagel 2016-05-21 21:03:56 UTC
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.
Comment 1 Pacho Ramos gentoo-dev 2016-05-24 10:04:00 UTC
You should provide one of that crashes at least to let maintainers to review them
Comment 2 Pacho Ramos gentoo-dev 2016-05-24 10:04:10 UTC
Also your emerge --info output
Comment 3 Matthias Nagel 2016-05-26 08:34:33 UTC
Sure, see attachments.
Comment 4 Matthias Nagel 2016-05-26 08:34:55 UTC
Created attachment 435438 [details]
emerge --info
Comment 5 Matthias Nagel 2016-05-26 08:44:56 UTC
Created attachment 435446 [details]
Backtrace #1
Comment 6 Matthias Nagel 2016-05-26 08:45:16 UTC
Created attachment 435448 [details]
Backtrace #2
Comment 7 Mike Gilbert gentoo-dev 2016-06-17 21:46:41 UTC
I have no idea what's up here. Maybe the toolchain guys will have an idea.
Comment 8 SpanKY gentoo-dev 2016-06-18 15:51:25 UTC
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.
Comment 9 Matthias Nagel 2016-06-18 16:17:36 UTC
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.)
Comment 10 SpanKY gentoo-dev 2016-06-19 20:25:20 UTC
(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.
Comment 11 Matthias Nagel 2016-06-19 20:40:03 UTC
(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.
Comment 12 Matthias Nagel 2016-12-04 17:04:00 UTC
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.
Comment 13 SpanKY gentoo-dev 2016-12-05 18:47:24 UTC
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.
Comment 14 Sergei Trofimovich (RETIRED) gentoo-dev 2018-11-27 23:19:06 UTC
Matthias, do you still have then problem of crashes using revdep-rebuild or should we close the bug as obsolete?