Description of problem: A bug in rtld.c or about causes all kinds of crashes. I just experienced a crash in evolution when creating a new email message and pressing "To:". This occurence also sort of froze a mozilla instance (couldn't use links or enter urls and couldn't restart mozilla before logging out and in). Crash dump follows in comment. This bug seems to be related to bug #104284 (gnome-terminal) which I can reproduce every time (crash dump follows), bug #113284 (gnome-terminal, look for crash dump in bug report). Since I have also seen evolution crashing on machine shutdown I suspect bug #112736 is also related. Version-Release number of selected component (if applicable): $ rpm -q glibc glibc-2.3.2-101.4 $ rpm -q --qf "%{arch}\n" glibc i686 Note that I have reproduced bug #104284 with glibc-i386 as well (see that bug report for a crash dump). How reproducible: bug #104284 is reproducible any time on my machine.
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.