User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 Build Identifier: Gecko/2008032619 When accessing the the page Special:Allmessages on any typical wiki from Wikimedia FF3 beta5 takes down the whole desktop. Never seen anything like this, no output or crash report. Not even sure how much is this related to the Linux version I'm running (StartCom MultiMedia Linux ML-5.0.7), however FF2 displays the page just fine. I wonder if anybody else could confirm this as a bug... Reproducible: Always Steps to Reproduce: 1. Access the page Special:Allmessages on any recent version of Mediawiki Actual Results: Crashes the desktop entirely, must reboot. Expected Results: Display the page like in FF2
I can confirm. Fedora7, x86_64. No need to reboot, but X does crash.
Status: UNCONFIRMED → NEW
Ever confirmed: true
a *minimal* testcase could be very useful.
Thanks. Promoting it to "major" and "blocking" wanted... The fact that I have to reboot might be the result of a bug or configuration issue on my specific system, which doesn't happen on a new install...
Severity: normal → major
(In reply to comment #2) > a *minimal* testcase could be very useful. > I can't do anything beyond, have to reboot the system to get out of it...Does X report anything on your system?
When I open a console in a different machine and start firefox there (but use the :0.0 display), I get: "The application 'firefox-bin' lost its connection to the display :0.0; most likely the X server was shut down or you killed/destroyed the application." That's all.
#0 0x00000032d900cb8b in write () from /lib64/libpthread.so.0 #1 0x00000032d7c4650f in ?? () from /usr/lib64/libX11.so.6 #2 0x00000032d7c4b56f in ?? () from /usr/lib64/libX11.so.6 #3 0x00000032d7c2809a in XFlush () from /usr/lib64/libX11.so.6 #4 0x00000032df832548 in gdk_window_process_all_updates () from /usr/lib64/libgdk-x11-2.0.so.0 #5 0x00000032df83258a in ?? () from /usr/lib64/libgdk-x11-2.0.so.0 #6 0x00000032dc42d224 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #7 0x00000032dc43005d in ?? () from /lib64/libglib-2.0.so.0 #8 0x00000032dc43058e in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #9 0x00002aaab14c8461 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x6, mayWait=6414160) at /home/smaug/mozilla/mozilla_cvs/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:151 #10 0x00002aaab14c88a2 in nsBaseAppShell::OnProcessNextEvent (this=0x74f340, thr=0x6599d0, mayWait=1, recursionDepth=<value optimized out>) at /home/smaug/mozilla/mozilla_cvs/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:284 #11 0x00002aaaab271182 in nsThread::ProcessNextEvent (this=0x6599d0, mayWait=1, result=0x7fff8932c04c) at /home/smaug/mozilla/mozilla_cvs/mozilla/xpcom/threads/nsThread.cpp:497 #12 0x00002aaaab22efb7 in NS_ProcessNextEvent_P (thread=0x6, mayWait=1) at nsThreadUtils.cpp:227 #13 0x00002aaab14c85c2 in nsBaseAppShell::Run (this=0x74f340) at /home/smaug/mozilla/mozilla_cvs/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170 #14 0x00002aaab2427099 in nsAppStartup::Run (this=0x7a5ba0) at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:181 #15 0x00002aaaaaae9f43 in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>) at /home/smaug/mozilla/mozilla_cvs/mozilla/toolkit/xre/nsAppRunner.cpp:3170 #16 0x0000000000400eba in main (argc=3, argv=0x0) at /home/smaug/mozilla/mozilla_cvs/mozilla/browser/app/nsBrowserApp.cpp:158
I guess you didn't want to mark blocking22.214.171.124? That is FF2 and you said FF2 works ok.
Component: DOM: Core → GFX: Gtk
QA Contact: general → gtk
This is clearly an X bug, we should not be able to take down the X server. Try running --sync to see what exactly we're doing to make the X server go down?
(In reply to comment #7) > I guess you didn't want to mark blocking126.96.36.199? That is FF2 and you said FF2 > works ok. > Outshhh, yes, meant FF3, is that the 1.9 branch? (In reply to comment #8) > This is clearly an X bug, we should not be able to take down the X server. > > Try running --sync to see what exactly we're doing to make the X server go > down? > My system is an i386 as opposed to the x86_64 output from above. Using glib2-2.12.3, gtk2-2.10.4, glibc-2.4 (following the stacktrace)
please indicate your xserver vendor/version information. you should also check your xserver log (and or enable core dumps for your xserver)
Xorg server infos from me: X Window System Version 7.1.1 X Protocol Version 11, Revision 0, Release 7.1.1 Current Operating System: Linux apache-2.internal.startcom.org 188.8.131.52-1.rt12.3.ML5rt #1 SMP PREEMPT RT Sat Dec 8 19:50:28 EST 2007 i686 Build Date: 28 February 2008 Build ID: xorg-x11-server 1.1.1-48.26.ML5.5
If we find this is an issue in Fx3 and not an X bug, re-nom.
Flags: blocking1.9? → blocking1.9-
Well, until the complains will come in...FF2 and lower works correctly, so I wonder what exactly is causing the crash. Are there others which can positively confirm this crash on other Linux versions?
I have a similar crash with large Wikipedia pages (>350 KB approx.), like the following one: http://de.wikipedia.org/wiki/Wikipedia:L%C3%B6schkandidaten/27._August_2007 This page crashes X and takes me to the login screen. It occurs on two different machines, an Athlon XP 2400+/512M RAM and a Pentium 3-933 with 256 K RAM. I am using Firefox3 Final (3.0-1pclinuxos2007) and PCLinuxOS 2007 on both machines.
I think this bug on the X.org bugzilla site is related to the same issue: http://bugs.freedesktop.org/show_bug.cgi?id=15409
Resolving INVALID -- as roc said, we should not be able to crash the X server. If it crashes, it's an X bug.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.