Created attachment 561198 [details] firefox_GUI_goes_to_dev_null.png User Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20100101 Firefox/6.0.2 Build ID: 20110906102300 Steps to reproduce: I started firefox 6.0.2 on my Ubuntu 10.10 computer. Some useful information: FF runs on the control of the Linux 2.6.35-30-generic-pae kernel, with the NX bit set (NX bit set and (32-bit PAE kernel or 64-bit kernel) prevents Adobe Flash from writing to the memory of Firefox=Firefox doesn't crash, but the Flash plugin does). Network connection is via Huawei E1752 3G (GPRS/UMTS/HSPA) USB modem. Actual results: Case I: Firefox didn't showed up on the desktop, not even an desktop icon. Instead it claimed that firefox was started, wich it wasn't. Case II: Firefox showed a blank (white) screen with no user interface components on it, see the attached image, please. Case I happend first, it was solved by doing this: kill -9 $(pgrep firefox) Then Case II began to show. Expected results: Case I: Firefox should had shown itself after being started. Case II: Firefox should draw its GUI. Case II was fixed with this workaround: 1) Remove USB 3G modem Here Firefox goes out of the livelock, and immidiately draws the GUI, and on each and every tab FF displays that it cannot connect to the websever. I guess it goes out of blocking call on every tab with an error from the kernel telling there are no internet connection. 2) Reconnect it 3) Enter PIN code 4) for each tab: click try reconnect again button I discovered the connection troubles with LostIRC (a simple IRC client), wich wrote Error Cannot connect to server. In my opinion Firefox should draw its GUI no matter whether there is a internet connection or not.
I think PAE and NX bit can be quite common configuration, this problem should have come up frequently. Can you run Firefox from the xterminal and see if there are any messages? Please see if you also have the issue also in Safe Mode - http://kb.mozillazine.org/Safe_Mode
Firefox works flawlessly now, my workaround solved the problem, but I am sure the problem will show up again. To me this problem looks like a concurrency-related one, and like a lot of other concurrency problems they are not easy to reproduce. The problem only shows up now and then. This problem is the 4th in approx the last couple of months. @acemon Your suggestion +safe mode sounds a good suggestion for that I should do the next time this problem shows up again. I will do that together with a strace on the process.
I should maybe make it clear what the workaround is normally not necessary to start Firefox with a GUI. Today Firefox started normally.
Understand, if it depends on some other circumstances in the system it will be hard to test. Are you able to test it with the device on another machine maybe without PAE/NX off? Or can you temporarily try kernel without it? How did you find out it has something to do with PAE/NX?
Summary: Blank (white) screen on Statup with FF 6.02 on Linux 2.6.35-30-generic-pae, with the NX bit set → Blank (white) screen (no GUI) on Startup with FF 6.0.2 on Linux 2.6.35-30-generic-pae, with the NX bit set
>Are you able to test it with the device on another machine maybe without PAE/NX off? No. >Or can you temporarily try kernel without it? Yes, I can change the BIOS setting wich switch the NX bit on or off, but i can only test it, when the problem shows up again. However i can't see why i should turn off the NX bit, because Firefox is programmed in C++ and it should *NOT* execute self-modifying code in data segments - that is exactly what malicious code does in a buffer overflow attack. Swithing the NX bit on should make it possible to discover a problem, where it occurs/earlier. But ok, for a simple test, it should be ok, when the the problem reoccurs. The problem is simply hidden now, but as i had wrote before, concurrency troubles is hard to reproduce, and can easily exsist inside the Firefox software only. >How did you find out it has something to do with PAE/NX? You had misinterpreted something. The "Some useful information" is a kind of FYI. I do only use a PAE kernel + have the NX bit set to prevent Abobe Flash from crashing the Firefox process, and preventing malicious code to do buffer overrun attacks. It is _very_ nice to just press F5* to reload a webpage, where the Adobe Flash plugin crashed, instead of having the Adobe Flash plugin crashing Firefox. *: ok very rarely Adboe Flash deadlocks the Firefox process, and in that case a SIGHUP to the Firefox process is needed.
Thanks for your repl, aceman I will do a report next time the Flash plugin crashes. I will report here again with more details, if my problem reoccurs.
(In reply to Lars T. Hansen from comment #7) > I will do a report next time the Flash plugin crashes. Only if it takes whole Firefox with it.
Can you still reproduce this issue on current Firefox builds?
I had not been capable of reproducing the bug on the latest stable Firefox since the beginning of 2012. Because I cannot reproduce the bug for such a long time, I guess the bug doesn't exist any longer, so I had changed the status of this bug from UNCONFIRMED to RESOLVED, WORKSFORME. I am only a user of Firefox that tries to help with bugs I had discovered, so if the status I had choosed is incorrect, then feel free to change it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.