[Solved] Firefox strangely crashing on one computer but not

[claude]

Try in a console killall firefox to kill any invisible instances so you can try restarting ff. After ruling out openGL and graphics we can move on.

root@porteus:~# killall firefox
firefox: no process found

Yet, when I restart ff, the ff "Close Firefox" window still pops up:

"Firefox is already running, but it is not responding. To open a new window, you must first close the existing firefox process, or restart your system."

Do you think that activating the "save changes" feature will allow me to shut off the system and then
restart it with the changes that were made to firefox, even if it was not completely closed?

[brokenman]

It should do. The changes occur in /home/guest/.mozilla. You could also use the Porteus Settings Centre to set up a 'magic folder' for the .mozilla folder which will monitor and keep the changes. I also recommend starting firefox from a console with: firefox --safe-mode

This will ensure no flashblocker or other extension is causing the zomby process after closing ff.

[claude]

@brokenman
Now listen to this...I tried to do the procedure you suggested, but this time in Porteus XFCE v1.2. Different behavior here: I was able to change webgl.disabled to 'true' (obviously after unchecking "smooth scrolling" and "hardware acceleration") and ff did not crash in v1.2. Was able to close it normally and restart it normally. This *without* using the "save changes" feature and without restarting ff in safe mode.

Upon restarting ff I got the "Warning: unresponsive script" window:

"A script on this page may be busy, or may have stopped responding. You can stop the script now, or you can continue to see if the script will complete."
Script: resource://gre/modules/XPCOMUtils.jsm:357

I clicked on continue, and it was accepted, ff started normally.

However, upon opening the usual local html document, ff crashed exactly as before.

I'm uploading the crash report and also psinfo here: http://pastebin.com/ET3BGW8C
(however psinfo is incomplete just as before, since it again crashed with "Failed to get size of gamma for output default.")

[claude]

After a bit of experimenting, I've been able to generate a full psinfo report in XFCE v1.2.
Before, I used to first 'su' into root and then from the root prompt type 'psinfo', and that's when I got the "xrandr: Failed to get size of gamma for output default" errors. But I have now discovered that by typing 'psinfo' at the guest prompt, and then entering the root password when prompted by the pop up window, I'm now able to generate a full psinfo report. I have no idea why this is so, but you guys probably know the reason already.
So, I have again changed webgl.disabled to "true", closed ff, restarted it and then had it crash again by opening the usual local html document, and after the crash I've generated a full psinfo report which is viewable here: http://pastebin.com/vHfZnW0C

Please let me know if you can understand what is going on and why the crashes are taking place. Thanks.

[fanthom]

@claude
there is following message:

Code: Select all

psmouse serio1: bad data from KBC - timeout

flooding your syslog. probably not related to ff issue but still it makes this system unusable in long run as growing log files will fill up tmpfs (RAM) quickly.

i would suggest you to upgrade to rc1 of porteus-2.0 which has logrotate utility (to help keeping log files in resonable size) and also newer kernel which may (or may not) resolve psmouse issue.

if crash will reoccur on rc1 then my second suggestion would be to try VESA driver.
please boot rc1 to text mode, then run 2 commands:

Code: Select all

cp /etc/X11/xorg.conf-vesa /etc/X11/xorg.conf
startx

if you get into gui then please check if ff still crashes.

[claude]

@fanthom

there is following message:

Code: Select all

psmouse serio1: bad data from KBC - timeout

flooding your syslog. probably not related to ff issue but still it makes this system unusable in long run as growing log files will fill up tmpfs (RAM) quickly.

Is there a way to cause Porteus to stop flooding syslog with that message? Or, even better, is there a way to fix that issue, that you know of?

i would suggest you to upgrade to rc1 of porteus-2.0 which has logrotate utility (to help keeping log files in resonable size) and also newer kernel which may (or may not) resolve psmouse issue.

oh, as I described in my latest posts, I was using 2.0-rc1 and was getting exactly the same crashes in ff... I've reverted to v1.2 only today, because, as I wrote, after changing webgl.disabled (in ff config) to "true" in a test suggested by brokenman, v2.0-rc1 caused ff to not close cleanly after making that change, but this problem does not occur with v1.2. I'll boot v2.0-rc1 tonight and look at syslog to see if the same flooding messages occur in v2.0-rc1 as well and will then report back on that. ff's crashing behavior on this laptop, however, is identical with both v1.2 and v2.0-rc1.

if crash will reoccur on rc1 then my second suggestion would be to try VESA driver.
please boot rc1 to text mode, then run 2 commands:

Code: Select all

cp /etc/X11/xorg.conf-vesa /etc/X11/xorg.conf
startx

if you get into gui then please check if ff still crashes.

I will try your second suggestion tonight when I get home, and I'll then report back. Thanks.

[claude]

@fanthom

i would suggest you to upgrade to rc1 of porteus-2.0 which has logrotate utility (to help keeping log files in resonable size) and also newer kernel which may (or may not) resolve psmouse issue.

You are right, I booted v2.0-rc1 and after a while checked /var/log/syslog: there was only one single instance of:

Code: Select all

psmouse serio1: bad data from KBC - timeout

It does an extremely good job at keeping log files small, however the psmouse issue is still there.
Also, as I said, ff crashes exactly in the same way as in v1.2. Moreover, there are a few glitches in v2.0-rc1 that are not present in v1.2 (at least, as far as this compaq 1670 laptop goes): for instance, ff cannot be closed cleanly; and the system is uncapable of generating a full psinfo report, as it crashes with the xrandr error mentioned above.
v1.2 gives me the impression of being more robust, more solid, more reliable.

if crash will reoccur on rc1 then my second suggestion would be to try VESA driver.
please boot rc1 to text mode, then run 2 commands:

Code: Select all

cp /etc/X11/xorg.conf-vesa /etc/X11/xorg.conf
startx

if you get into gui then please check if ff still crashes.

Yes, I was able to get into the VESA gui and to start firefox, but it crashed exactly in the same fashion as before upon opening the usual local html document. The icons on the taskbar were no longer visibile, just clusters of pixels, and the terminal console was unusable, but the other programs would start just fine, as did ff. Surprisingly, this VESA gui is in no way any faster than regular xwindows on this laptop.

[brokenman]

So i think we have come back around to one of fanthom's earlier suggestions of downgrading firefox and seeing what happens. Firefox moves with technology and as platforms change they change coding. It may not be that recent version are 'more demanding' but just handle requests differently. If i upload a firefox from Porteus v09 would you be willing to try it?

For your mouse you could try two things:

Code: Select all

modprobe -rv psmouse && modprobe -v psmouse proto=imps

See if the problem persists

Code: Select all

modprobe -rv psmouse && modprobe -v psmouse proto=exps

[claude]

@brokenman

If i upload a firefox from Porteus v09 would you be willing to try it?

Thanks, of course I will try it. Is this an xzm module I can put in the base directory of XFCE-v2.0-rc1?

For your mouse you could try two things:

Code: Select all

modprobe -rv psmouse && modprobe -v psmouse proto=imps

See if the problem persists

Code: Select all

modprobe -rv psmouse && modprobe -v psmouse proto=exps

I just did and in both cases /var/log/syslog got quickly populated with the usual error message after using the mouse to open and close a few graphic applications, unfortunately. Just in case, I also tried opening the usual html document with ff, and ff crashed as usual in each instance.

[brokenman]

Here is a link to the version of firefox we used in Porteus-v09. You can replace the current firefox module you have in base folder with this one.

http://dl.dropbox.com/u/6868871/008-firefox.xzm

[claude]

Here is a link to the version of firefox we used in Porteus-v09. You can replace the current firefox module you have in base folder with this one.

http://dl.dropbox.com/u/6868871/008-firefox.xzm

Just downloaded it, thanks...I'll give it a try tonight and let you know.

I have some feedback which may mean something to you, or maybe not. Did some experimenting by first booting live XFCE-2.0-rc1 then transferring it to an ext4 partition and booting it there (not a frugal install but booted as regular slackware). I wanted to see how ff performed with a less demand on the PC's ram. In this case ff was able to start and to finally open the usual html document (which had always failed to do before) and other local documents, only to crash but this time with more "mileage" . Interestingly, I could open all tabs in ff preferences except for the Applications one.....upon clicking on Applications it would immediately crash each and every time.
So, at this point do you think ff's behavior could be caused by lack of adequate PC resources or what else?
Thanks...

[brokenman]

Yes, your further testing does indicate that RAM is the problem as first suspected.

[claude]

@brokenman

I just tried out your ff v3.6.12 from Porteus 0.9 and it works perfectly on my "problem laptop" without a glitch. I even tried overloading it with multiple large html documents, but it is very stable on my system and does not crash at all. Question: did you do anything to it other than unchecking "smooth scrolling" and "hardware acceleration" in preferences, or is this pretty much what shipped out with Porteus 0.9?
Should I stick to ff v3.6.12 on this laptop with xfce v2.0-rc1, or should I go for a more modern browser less demanding on hardware resources, in your opinion? Do you have one in mind that is a good match to xfce v2.0-rc1?

Perhaps it should be stated in the requirements section of this project that even xfce needs much more than a 486 machine with a meager 128 MB of RAM.....realistically, more like a pentium 3 or AMD equivalent with 256 MB of RAM (maybe even 384 MB) *minimum* in my opinion (to run firefox). I tried booting xfce v2.0-rc1 on my toshiba portege PII 266 MHz, 96 MB of RAM and it took five minutes just to load xwindows...

By the way, I've downloaded and tried out Porteus v2.0-rc1 (full version) on my faster laptop tonight and I have to say that I am VERY impressed. It's a great leap forward from v1.2......I very much love it so far and I'm going to stick to it, it's a great little system, the very best thing of its kind I've come across recently. KUDOS to you guys for the great work and for all the dedication you are putting in on this forum. Really, really excellent.

[brokenman]

Ok great. Glad that is resolved. The firefox i uploaded was stock standard in v09 with nothing changed. Just converted from squashfs3 to squashfs4.

After reading up on firefox i see that they continually develop for the future which means compatibility for older hardware takes a hit. In the case of GPU drivers they only support after a certain version of driver. Perhaps chromium or google-chrome could be your answer as (for me, compared to firefox) the more recent versions do not run like honey on a cold day. Not sure if they require a big chunk of ram to run though.

We will review the minimum requirements for all versions to be sure they are accurate. Perhaps i will go ahead with the minimal 'skinny' version of Porteus with just openbox. In the 'Porteus derivatives' section Ahauu also made a 'super fly' version which is super light. These versions shouldn't require too much overhead.

[claude]

@brokenman

You know, my reason for asking whether it was original Porteus 0.9 material is that I noticed some
peculiar behavior in the small ff. It worked perfectly, just as I said, in unmodified Porteus Xfce 2.0-rc1.
But when I tried it out after customizing a few /etc files in Porteus, such as HOSTNAME, hosts.allow,
hosts.deny through the rootcopy directory, here is what I noticed: if I placed your ff in the base directory,
upon booting the system ff reverted my modified /etc files to their originals.....very very strange, for instance hostname reverted to porteus, permissions I had changed reverted to the originals, etc...; if I booted Porteus without your ff into base directory and activated the module from within booted Porteus after booting the system, then ff would not start at all, since I guess it was prevented from changing things around.

As far as skinny Porteuses, I've just looked in the derivatives section and read about Ahau's "super fly"...
You know what I think would make a good super small porteus? I tried Porteus Kiosk a few days ago...
I think that if it could be made to boot on an ext4 writable partition, made accessible through login, with a very light graphic text editor such as beaver, shell console and a thin file manager such as an older version of standalone mc compiled in C with only very basic features (it can be made very small) and the latest firefox....I think it could run on pretty old hardware (including mine ) and provide a very very light system with a truly useful browser, not something limited like midori or epiphany etc.
I was thinking of trying to do that myself, to modify Kiosk in this manner, but I'm very limited compared to what you guys are capable of doing in a tiny fraction of the time it would take me.
If you have the time, why don't you do it yourself? :):) Imagine: Porteus Kiosk at about 30-40 MB compressed and providing a writable filesystem, a light text editor, shell console to login...... it could be an excellent solution to run the latest firefox on older hardware......limited in its use yes, but nevertheless it would be great and would bring a lot of old laptops back to life, and in a very useful way.