Mediawiki Special:Allmessages crashes dekstop



Core Graveyard
GFX: Gtk
10 years ago
9 years ago


(Reporter: Eddy Nigg (StartCom), Unassigned)


Bug Flags:
blocking1.9 -

Firefox Tracking Flags

(Not tracked)





10 years ago
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

Comment 1

10 years ago
I can confirm. Fedora7, x86_64.
No need to reboot, but X does crash.
Ever confirmed: true

Comment 2

10 years ago
a *minimal* testcase could be very useful.

Comment 3

10 years ago
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
Flags: blocking1.8.1.15?

Comment 4

10 years ago
(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?

Comment 5

10 years ago
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.

Comment 6

10 years ago
#0  0x00000032d900cb8b in write () from /lib64/
#1  0x00000032d7c4650f in ?? () from /usr/lib64/
#2  0x00000032d7c4b56f in ?? () from /usr/lib64/
#3  0x00000032d7c2809a in XFlush () from /usr/lib64/
#4  0x00000032df832548 in gdk_window_process_all_updates () from /usr/lib64/
#5  0x00000032df83258a in ?? () from /usr/lib64/
#6  0x00000032dc42d224 in g_main_context_dispatch () from /lib64/
#7  0x00000032dc43005d in ?? () from /lib64/
#8  0x00000032dc43058e in g_main_context_iteration () from /lib64/
#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

Comment 7

10 years ago
I guess you didn't want to mark blocking1.8.1.15? That is FF2 and you said FF2 works ok.
Component: DOM: Core → GFX: Gtk
Flags: blocking1.8.1.15?
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?

Comment 9

10 years ago
(In reply to comment #7)
> I guess you didn't want to mark blocking1.8.1.15? 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)
Flags: blocking1.9?

Comment 10

10 years ago
please indicate your xserver vendor/version information.

you should also check your xserver log (and or enable core dumps for your xserver)

Comment 11

10 years ago
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 #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-

Comment 13

10 years ago
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?

Comment 14

10 years ago
I have a similar crash with large Wikipedia pages (>350 KB approx.), like the following one:

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.

Comment 15

10 years ago
I think this bug on the bugzilla site is related to the same issue:
Resolving INVALID -- as roc said, we should not be able to crash the X server.  If it crashes, it's an X bug.
Last Resolved: 10 years ago
Resolution: --- → INVALID

Comment 17

10 years ago


9 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.