Firefox crashes on start

[tangobravo]

I've got a (staticly linked) build of firefox-2.0.0.6 that I've been trying on Haiku. It always segfaults on start-up but the exact place varies.

My gut feeling is it's a lack of memory issue as the segfault sometimes occurs in BPrivate::threadHeap::malloc() - are there any constants for heap size or anything I can enlarge to see if that helps?

I'll keep investigating and try and get a simplified test case

[axeld]

If you have enough memory, the heap should well grow over 1 GB. Also, the heap allocation would not crash then, it would just fail. It looks like there is some memory corruption happening, though. Have you tried to run that build with MALLOC_DEBUG=15 on BeOS (set as env variable on startup in a BONE BeOS or one with a libroot.so version that support that)?

Either way, the runtime loader does not use the heap - it has its own heap, so if it's not Firefox itself, it could also be a bug in some other userland library like libroot.so, or libbe.so.

[tangobravo]

This is being posted from R5 with MALLOC_DEBUG=15 (through VMWare so I get net access with my wireless card) and it seems to work OK. I've also tested it natively with success. I checked MALLOC_DEBUG was doing something with a little

delete myBView;
myBView->Bounds();

which crashed with it and not without.

I'll attached part of a backtrace - all the nsDrawingSurface destructor does is call delete on a bitmap.

Perhaps "on start" in the title is misleading - the main window is created, and on some starts is even drawn before the crash.

[tangobravo]

back trace of one crash (not always the same)

[kvdman]

I've attached a bt from ff2.0.8, it's different from the previous attachment.

[kvdman]

There seems to be a lot more errors if you start from an empty profile, bt attached. This is on rev22677 btw.

[tqh]

Are there any error messages to accompany those backtraces?

[kvdman]

I copied the libraries in /components and in the root directory over to /home/config/settings/lib. It now almost starts, but seems to be lots of errors!

GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-pc-haiku"...(no debugging symbols found)

[tcsetpgrp failed in terminal_inferior: Invalid Argument] Thread 547 caused an exception: Segment violation Reading symbols from /ZETA/home/Desktop/firefox/libmozjs.so...(no debugging symbols found)...done. Loaded symbols for /ZETA/home/Desktop/firefox/libmozjs.so Reading symbols from /ZETA/home/Desktop/firefox/libxpcom.so...(no debugging symbols found)...done. Loaded symbols for /ZETA/home/Desktop/firefox/libxpcom.so Reading symbols from /ZETA/home/Desktop/firefox/libxpcom_core.so... (no debugging symbols found)...done. Loaded symbols for /ZETA/home/Desktop/firefox/libxpcom_core.so Reading symbols from /ZETA/home/Desktop/firefox/libplds4.so...(no debugging symbols found)...done. Loaded symbols for /ZETA/home/Desktop/firefox/libplds4.so Reading symbols from /ZETA/home/Desktop/firefox/libplc4.so... (no debugging symbols found)...done. Loaded symbols for /ZETA/home/Desktop/firefox/libplc4.so Reading symbols from /ZETA/home/Desktop/firefox/libnspr4.so...(no debugging symbols found)...done. Loaded symbols for /ZETA/home/Desktop/firefox/libnspr4.so Reading symbols from /boot/beos/system/lib/libbe.so... (no debugging symbols found)...done. Loaded symbols for /boot/beos/system/lib/libbe.so Reading symbols from /boot/beos/system/lib/libroot.so...done. Loaded symbols for /boot/beos/system/lib/libroot.so Reading symbols from /boot/beos/system/lib/libtracker.so...done. Loaded symbols for /boot/beos/system/lib/libtracker.so Reading symbols from /boot/beos/system/lib/libgame.so...done. Loaded symbols for /boot/beos/system/lib/libgame.so Reading symbols from /ZETA/home/Desktop/firefox/libsmime3.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libsmime3.so Reading symbols from /ZETA/home/Desktop/firefox/libssl3.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libssl3.so Reading symbols from /ZETA/home/Desktop/firefox/libnss3.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libnss3.so Reading symbols from /ZETA/home/Desktop/firefox/libsoftokn3.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libsoftokn3.so Reading symbols from /ZETA/home/Desktop/firefox/libxpcom_compat.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libxpcom_compat.so Reading symbols from /boot/home/config/lib/libstdc++.hrev4.so...done. Loaded symbols for /boot/home/config/lib/libstdc++.hrev4.so Reading symbols from /boot/beos/system/lib/libnetwork.so...done. Loaded symbols for /boot/beos/system/lib/libnetwork.so Reading symbols from /boot/beos/system/lib/libtranslation.so...done. Loaded symbols for /boot/beos/system/lib/libtranslation.so Reading symbols from /boot/beos/system/lib/libmedia.so...done. Loaded symbols for /boot/beos/system/lib/libmedia.so Reading symbols from /boot/beos/system/lib/libtextencoding.so...done. Loaded symbols for /boot/beos/system/lib/libtextencoding.so Reading symbols from /ZETA/home/Desktop/firefox/components/libmyspell.so...done.Loaded symbols for /ZETA/home/Desktop/firefox/components/libmyspell.so Reading symbols from /ZETA/home/Desktop/firefox/libfreebl3.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libfreebl3.so Reading symbols from /ZETA/home/Desktop/firefox/libnssckbi.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/libnssckbi.so Reading symbols from /ZETA/home/Desktop/firefox/components/libspellchecker.so...done. Loaded symbols for /ZETA/home/Desktop/firefox/components/libspellchecker.so [tcsetpgrp failed in terminal_inferior: Invalid Argument]

[Switching to team /ZETA/home/Desktop/firefox/firefox-bin (547) thread firefox-bin (547)] 0x00bcb43d in nsGlobalWindow::HandleDOMEvent () (gdb) bt #0 0x00bcb43d in nsGlobalWindow::HandleDOMEvent () #1 0x00ba54ba in nsXULDocument::HandleDOMEvent () #2 0x00b9a323 in nsXULElement::HandleDOMEvent () #3 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #4 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #5 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #6 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #7 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #8 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #9 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #10 0x00b9a2d8 in nsXULElement::HandleDOMEvent () #11 0x00b9cd8f in nsXULElement::HandleChromeEvent () #12 0x00bcb69b in nsGlobalWindow::HandleDOMEvent () #13 0x00adb54a in nsDocument::HandleDOMEvent () #14 0x00aeface in nsGenericElement::HandleDOMEvent () #15 0x0095c9bd in PresShell::HandleEventInternal () #16 0x0095c57f in PresShell::HandleEvent () #17 0x00bbd88c in nsViewManager::HandleEvent () #18 0x00bbcc85 in nsViewManager::DispatchEvent () #19 0x00bb5f5d in HandleEvent () #20 0x008fc17f in nsWindow::DispatchEvent () #21 0x008fc1fd in nsWindow::DispatchWindowEvent () #22 0x00901209 in nsWindow::DispatchMouseEvent () #23 0x008fff7c in nsWindow::CallMethod () ---Type <return> to continue, or q <return> to quit--- #24 0x0090895f in nsAppShell::Run () #25 0x00ebd9d1 in nsAppStartup::Run () #26 0x0069dd2a in XRE_main () #27 0x00697e46 in main () (gdb)

[kvdman]

Attached a screenshot of some errors displayed before it loads...

[tqh]

Most libs in Firefox are loaded by absolute path by Firefox itself, so shouldn't be moved. The ones that may be moved are the ones linked by the executable (firefox-bin) itself and the ones linked by those libs (and so on).

The stubs are an 'ugly hack' to get around BeOS R5's poor handling of addon memory. The stubs are just libs that link to the real lib, the stub gets loaded in addon memory and the libs in ordinary. In Haiku and Zeta I'd recommend to delete the stubs as the loading mechanism will fallback to loading the real lib instead.

[tqh]

I've installed Haiku and used my Firefox from BeOS, and to me it crashes on free as well. It is in the same place the few times I've tried.

Here is the code in Firefox: ​http://lxr.mozilla.org/mozilla1.8.0/source/gfx/src/beos/nsRenderingContextBeOS.cpp#870

To me this looks ok, making me wonder if there is a bug somewhere in Haiku? Off by one error perhaps?

[tqh]

From the code it seems it would be possible to just 'new an array of BPoint's' and then 'delete [] them' to cause a seg fault.

Although threading and Firefox using a lot of memory might also affect this.

[marcusoverhagen]

There is an off-by-a-lot error in BPolygon::AddPoints() I'll fix that later.

[marcusoverhagen]

try hrev22887

[umccullough]

Not sure if it's significant, but I also get a crash in "free" immediately when trying to launch firefox with the safe-mode switch... don't have to wait for the app to load to reproduce it ;)

[kvdman]

Hi,

I tried Firefox 2.0.8 in hrev22888, and it works. For the first time menus even worked...

However hrev22888 seems very unstable. Takes long to boot, windows freeze, etc. Tested on Vmware. Will do more testing later.

[tqh]

Also test after removing your Firefox profile in /boot/home/config/settings/mozilla

As most backtraces seem to stem from the gfx code, it may have been the only problem, but there may be others.

[tqh]

Firefox launches here as well (BONE version). I wouldn't have thought of corrupted memory myself.

After launch it seems Firefox isn't responding well to the messages it receives. So there are at least issues which probably are related to these files (In order of probability): ​http://lxr.mozilla.org/mozilla1.8.0/source/widget/src/beos/nsWindow.cpp ​http://lxr.mozilla.org/mozilla1.8.0/source/widget/src/beos/nsAppShell.cpp ​http://lxr.mozilla.org/mozilla1.8.0/source/widget/src/beos/nsDragService.cpp ​http://lxr.mozilla.org/mozilla1.8.0/source/widget/src/beos/nsToolkit.cpp

(I havn't tested with a working network, havn't figured out what needs to be done yet to enable it.)

[umccullough]

Well, the FF 2.0.0.10pre version I grabbed from R5 net_server worked in Haiku also. I used an empty profile from my R5 box rather than allowing it to be re-created within Haiku.

I didn't get a chance to re-test the -safe-mode switch because Haiku hung on me shortly after creating a screenshot and trying to upload to my flickr page (yeah, from Haiku directly - I know, brave)...

Nice to hear the BONE version works!

[umccullough]

I should probably note that I also still had problems with mouse events - this has always been an issue with firefox in Haiku, but keyboard controls seem to work fine.

[axeld]

Okay, so the bug has been fixed with hrev22887. If there is no open bug report that complains about the interface, please file one :-)

BTW I still have the crash in "NSPR_PollEvent" or something named similarly with the BONE version (2.0.0.9 from BeBits); the R5 version works fine here, though.

[tqh]

Can't help without seeing a backtrace.

[umccullough]

I created #1620 for the safe-mode crash which still occurs.

[kvdman]

I couldnt get FireFox 2.0.0.9 to crash (just freezes randomly), so I tried a really old 1.0 version from 2005...

"NSPR_PollEvent" seems to be the culprit (as described above by Axel), and I've included a screenshot (ff1.0-bt.jpg) to show this.

Seems it can't access memory. I believed Marcus' commit earlier addressed a bug like this also..

[tqh]

Testing with a really old one doesn't really say much as we have little knowledge how it differs from recent ones, although it may give some interesting traces.

The 2.0.0.9 you used is it the repackaded one by tigerdog. As I use (and he in that build) an improved NSPR library, the problem may be in the ordinary one. Although if you used something else it's not so likely.

[marcusoverhagen]

The original bug report converning firefox-2.0.0.6 crashing during startup was fixed.

It's not really nice to reopen this bugreport to report that a 3 year old Firefox 1.0 version crashes.

I'm out.

[axeld]

Replying to kvdman:

"NSPR_PollEvent" seems to be the culprit (as described above by Axel), and I've included a screenshot (ff1.0-bt.jpg) to show this.

Please don't reopen bugs. This bug has nothing to do with the original bug which Marcus just fixed. I'll open a new bug report for this one as soon as I have a stack crawl to show.