Red Hat Bugzilla – Bug 509574
Firefox hangs or crashes depending on phase of moon
Last modified: 2018-04-11 08:53:03 EDT
Description of problem: Firefox 3.5 crashes (if you're lucky) or hangs X server (if you're not).
Version-Release number of selected component: 3.5 (plus 1000 or so dependencies all yum'd up as of today).
Steps to Reproduce:
0. It certainly helps to add offending URL (submitted with this bug) to the "Bookmarks toolbar".
1. Set preferences "When Firefox starts" to "Show a blank page", then exit Firefox.
2. In a terminal "debuginfo-install firefox", and go have coffee.
3. In a terminal, "firefox -g -safe-mode" then (to GDB prompt), "r".
4. In the "Firefox Safe Mode" dialog, click "Continue in Safe Mode". NOTE: KDE's window manager may bury this dialog under other open windows. Thus, you sometimes will have to fish for it.
5. [Optional] Click "Start new session" on "Well, This is embarrassing" dialog (caused by earlier crash). Snicker as Firefox mistakenly loads your home page instead of doing what you asked.
6. Cut/paste offending URL (submitted with this bug) into URL field of "Navigation toolbar" and press Enter (or click bookmark icon)
7. After "Done" disappears from "Status Bar" and is replaced by "starting applet...", but before the animation data have finished loading, try to select an item from the "File" submenu.
8. If you're unlucky, Firefox will hang the X server. Ctl-Alt-Backspace thankfully will terminate the X session. You'll have to "killall -9 firefox" and go back to step 3, accompanied by much cursing and gnashing of teeth. If you're running the Gnome or KDE bloatware, you'll have time for another cup of coffee.
9. If you're lucky, and Firefox fails without hanging the X server, gdb will probably announce that you need to "debuginfo-install" (for me) a hundred more "-debug" packages. Do that now, and return to step 3. You now have time for lunch.
10. If gdb does regain control, the session will resemble:
Starting program: /usr/lib64/firefox-3.5/firefox '-safe-mode'
[Thread debugging using libthread_db enabled]
[New Thread 0x7f26d98ff910 (LWP 9722)]
Detaching after fork from child process 9725.
[Thread 0x7f26d5c9f910 (LWP 9728) exited]
[Thread 0x7f26ceffe910 (LWP 9735) exited]
firefox: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.
[Thread 0x7f26cc17c910 (LWP 9749) exited]
Java Runtime Version = 1.6.0_0
Program exited with code 01.
!!!! Problem: java.security.AccessControlException: Applets may not call System.exit()
a. ":" means "similar lines elided".
b. "I've only seen "!!! Problem java.security ..." one time. More typically it's missing.
c. I've inserted some blank lines for clarity.
11. If Firefox hangs the X server, you *can* Ctl-Alt-F2 to get a real terminal, and "killall -9 firefox". Alas, Alt-F7 back to X, and gdb is confused. At least you can copy/paste the sysgem/gdb messages. There are a dazzling array of such messages, but here is one example:
Java Runtime Version = 1.6.0_0
firefox: xcb_io.c:242: process_responses: Assertion `(((long) (dpy->last_request_read) - (long) (dpy->request)) <= 0)' failed.
Program received signal SIGABRT, Aborted.
0x00000036916332f5 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
Actual results: Firefox crashes as shown. "ps -e" shows loads of <defunct>
Expected results: Applet loads and runs. Firefox remains responsive.
Additional info: Intel ION dual-core Atom mobo.
*** This bug has been marked as a duplicate of bug 509501 ***