Bug 115248
Summary: | Bug in _dl_start / rtld.c causes all kind of crashes | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Leonard den Ottolander <leonard-rh-bugzilla> |
Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
Status: | CLOSED DUPLICATE | QA Contact: | Brian Brock <bbrock> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | 1 | ||
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-02-21 19:01:08 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Attachments: |
Description
Leonard den Ottolander
2004-02-09 16:01:07 UTC
Created attachment 97536 [details]
Crash dump of evolution crashing on pressing "To:" in new mail message
Created attachment 97537 [details] Crash dump of gnome-terminal (bug #104284) Why do you think this has anything to do with rtld.c? A crash in _dl_sysinfo_int80 means that the process segfaulted in the kernel and from the caller of _dl_sysinfo_int80 you can figure out what kind of syscall it was. In gnome-terminal case it was waitpid. Because the attached full dump for gnome-terminal says: 0x0096ec32 in ?? () at rtld.c:277 from /lib/ld-linux.so.2 That place is int 0x80 location (which can be replaced with kernel VDSO's entry point). Can you see what's going on in strace dump? (Please take my conclusions with a grain of salt. They are however an indication of where I already looked. But this issue seems to be somewhat over my head :) If you can briefly tell me how to do that, yes ;) . If I run strace gnome-terminal strace exits as soon as the terminal appears, so I can not reproduce the crash while it runs. The gnome-terminal crash is always reproducible. I never experienced the evolution crash before, but it now seems to appear all the time (if the last reboot didn't solve it). Could this be caused by the installation of the various -debuginfo rpms? By the way bug #112003 also seems to be a duplicate of this. And a question about _dl_sysinfo_int80: The 3 definitions seem to vary somewhat. I was mistaken about the tabs being relevant (didn't realize they are probably just formatting for the expanded macro), but what about the semicolons after "int $0x80;" and "ret;", are they valid syntax in asm? 112003 is in no way related to this. There has clearly been a segfault in gtk_widget_get_accessible and then the trace is from bug-buddy. Have you tried strace -f? ; in asm syntax is end of insn and obviously is valid syntax. bug #112003, attachment #96499 [details]: 0x0078cc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #0 0x0078cc32 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (The crash dumps I submitted are also coming from bug-buddy.) I did try strace -f on gnome-terminal, with the same result: It finishes as soon as the terminal appears. I'll attach the output in a few minutes, and see how far I get with evolution. Created attachment 97539 [details]
strace -f of evolution crashing on clicking "To:" in edit new message
Created attachment 97540 [details]
strace -f when starting gnome-terminal
Probably not very useful as strace -f ends as soon as the terminal appears, so
I can not reproduce the crash while gnome-terminal is running.
That of course should read: ... I can not reproduce the crash while strace is running. Are you telling me the mention of _dl_sysinfo_int80 is only caused by the fact that these crash dumps are generated by bug-buddy? So where should I look to locate the actual problem? The first dump entry after "<signal handler called>"? If that is so the gnome-terminal crash is unrelated, but this turns out to be a glibc issue after all (fortune favours fools ;-) : Thread 1 (Thread -1084721184 (LWP 5149)): #5 __libc_free (mem=0x8000000) at malloc.c:3341 ar_ptr = 0x9dac348 p = 0x7fffff8 hook = (void (*)(void *, const void *)) 0 (Sorry for the information overload. I'll stop after this until you request more.) Also worth comparing: bug #111981 Yeah, the line after <signal handler called> matters, or lines after that. Before that line you can often see even what signal was it: segv_redirect (sig=11) tells you it was a segfault. But, it is highly unlikely a segfault in free is glibc's fault. In 99.9% cases this is because of memory management bugs in the application or its libraries. efence etc. might tell you more. I think I'll have to file this under evolution then. The problem seems to be worse than I thought. Just editing the To: line crashes evolution. I am not sure why this did not happen before. Maybe caused by the swapping after installing all the debuginfo rpms? That should fix it after the next reboot now I did uninstall these. After I filed a new bug report I'll close this one as DUPLICATE. Or should I just change the component of this bug to evolution? You might want to make the three definitions of _dl_sysinfo_int80 consistent. They confused me :). The problem persists after uninstalling of all the -debuginfo rpms. But as you explained this is not a glibc issue, and since this report mentions gnome-terminal and other bugs as well it would probably be confusing to continue the bug in Evolution here. Closing as DUPLICATE and moving the discussion to bug #115308. *** This bug has been marked as a duplicate of 115308 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |