Opened 15 years ago

Closed 14 years ago

#1620 closed bug (fixed)

Firefox crashes with "-safe-mode" switch

Reported by: umccullough Owned by: axeld
Priority: normal Milestone: R1
Component: System/ Version: R1/pre-alpha1
Keywords: Cc: tqh, mjw
Blocked By: Blocking:
Platform: x86


The attached backtrace shows a crash when attempting to start Firefox (R5 net_server version) using the -safe-mode commandline switch using Haiku hrev22903 on a PIII 600 w/512mb RAM.

Without the -safe-mode switch, Firefox seems to load fine and can be used for a short period of time before the app_server appears to freeze.

I used an empty profile from my R5 machine when testing.

Attachments (2)

ff safe-mode crash (4.1 KB ) - added by umccullough 15 years ago.
backtrace of firefox safe-mode crash
Application.cpp.patch (354 bytes ) - added by mjw 14 years ago.

Download all attachments as: .zip

Change History (14)

by umccullough, 15 years ago

Attachment: ff safe-mode crash added

backtrace of firefox safe-mode crash

comment:1 by tqh, 15 years ago

As we don't seem to do anything with ArgvReceived (in this 2.0.X branch):

It must be related to how Firefox handles it and BApplication's ArgvReceived:

I can't see anything except that argv is passed straight thru to BApplication's method.

Maybe we should backport some code from trunk:

comment:2 by tqh, 15 years ago

Seems to be related to that switch only, so I wonder what Firefox does with that case.

comment:3 by mjw, 14 years ago

I have been working on freeciv and have noticed the same problem.

What happens in freeciv's case is that some elements of argv are set to NULL before the BApplication object is instantiated. argc is unchanged. Eventually, BApplication::_ArgvReceived() is called with the correct value of argc, but all the NULL elements of argv are missing (so argc > num elements in argv).

So, to cut a long story short, the free(argv[i]) call in _ArgvReceived() ends up freeing random pointers, causing the crash.

I have attached a patch that fixes this bug.

by mjw, 14 years ago

Attachment: Application.cpp.patch added

comment:4 by mjw, 14 years ago

Cc: mjw added

comment:5 by stippi, 14 years ago

The patch does not fix the error completely. The entire array needs to be initialized to NULLs, since an error could occur in the middle of loop. Then your patch would only initialize that entry, but break out of the loop early. Then the remaining items would still be uninitialized. But thanks for catching this one! (And sorry I forgot to credit you in the commit message, didn't intend to!)

Does hrev25494 also fix the Firefox problem?

comment:6 by mjw, 14 years ago

Oh yeah - missed that one. D'oh. Thanks.

comment:7 by umccullough, 14 years ago

I just tested firefox BONE (experimental build from bebits) on hrev25493 and the problem didn't even exist there, so it may have already been fixed sometime in the last 6 months.

Wish I'd noticed earlier - I'll try to track down the approximate timeframe that it got fixed if I can.

comment:8 by korli, 14 years ago

then it's fixed ?

comment:9 by umccullough, 14 years ago

It worked prior to hrev25494 (in fact, I tested back to 24500 and it even worked there I believe)

With hrev25536 now though, it spits some output to the terminal window that I hadn't seen before:

/boot/apps/firefox> firefox --safe-mode Error parsing B_ARGV_RECEIVED message. Message: BMessage('_ARG') {

argc = int32(0x2 or 2) argv = string("./firefox", 10 bytes) cwd = string("/boot/apps/firefox", 19 bytes)

} /boot/apps/firefox>

This was tested with Firefox BONE from the Experimental Build page on bebits.

I think this issue can safely be closed.

comment:10 by umccullough, 14 years ago

Just in case it wasn't clear - even with the output mentioned in my previous comment, it does start without crashing at least.

comment:11 by umccullough, 14 years ago

Someone please close! :)

comment:12 by mmlr, 14 years ago

Resolution: fixed
Status: newclosed

Fixed apparently.

Note: See TracTickets for help on using tickets.