Ticket #2197 (reopened bug)

Opened 7 months ago

Last modified 6 weeks ago

KDL when starting Firefox

Reported by: cebif Owned by: axeld
Priority: blocker Milestone: R1/alpha1
Component: Network & Internet/TCP Version: R1 development
Cc: tqh Blocked By:
Platform: All Blocking:

Description

When starting Firefox from firefox.bin or link to it, it almost always results in KDL. If starting it in Terminal from the firefox script it starts OK. I have the "UserSetupEnvironment" file in: /home/config/boot. I had to create the /boot folder I am using Firefox 2.0.0.12 and Haiku r25268 on its own partition. I will attach screen images of KDL with backtrace and my "UserSetupEnvironment" file. I don't think there is anything wrong with this file. It is the same one, a copy of the file I use in BeOSR5.05 Bone and no problems with it there. I have Firefox in the same folder in /apps as in BeOSR5.05 Bone.

Attachments

KDL Weh Starting Firefox 1.jpg (142.4 kB) - added by cebif 7 months ago.
KDL When Starting Firefox 2.jpg (197.3 kB) - added by cebif 7 months ago.
UserSetupEnvironment (226 bytes) - added by cebif 7 months ago.

Change History

Changed 7 months ago by cebif

Changed 7 months ago by cebif

Changed 7 months ago by cebif

  Changed 7 months ago by axeld

  • owner changed from axeld to hugosantos
  • priority changed from normal to blocker
  • component changed from Applications to Network & Internet/TCP
  • milestone changed from R1 to R1/alpha1

  Changed 7 months ago by axeld

  • owner changed from hugosantos to axeld

TCP still had Hugo as owner, but I'm afraid that's another component for me now :-)

follow-up: ↓ 4   Changed 7 months ago by tqh

  • cc tqh added

That UserSetupEnvironment seems to be broken. Has it gone broken when uploading or is that so? Look at end of second line.

in reply to: ↑ 3   Changed 7 months ago by cebif

Replying to tqh:

That UserSetupEnvironment seems to be broken. Has it gone broken when uploading or is that so? Look at end of second line.

Yes it is broken I think from looking at it now. It is the same uploaded as on my system both Haiku and BeOSR5.05 Bone. I don't know why it was sensitive to the error (not all times) in Haiku and not in BeOSR5.05 Bone.It looks like a ":" and "A" was missing in that order.

follow-up: ↓ 7   Changed 7 months ago by tqh

So when you corrected that it works correctly?

  Changed 7 months ago by kaliber

Is it a duplicate of bug #2189?

in reply to: ↑ 5 ; follow-up: ↓ 11   Changed 7 months ago by cebif

Replying to tqh:

So when you corrected that it works correctly?

Yes, I have retested with corrections to UserSetupEnvironment and it has not crashed at startup.

  Changed 7 months ago by tqh

This bug can be closed.

  Changed 7 months ago by stippi

Actually, this hints to a problem in the runtime loader, if all it takes is a corrupt PATH variable to trigger a kernel panic under certain conditions. So I would leave this bug open.

  Changed 7 months ago by tqh

Yes, although I saw it is a different bug.

in reply to: ↑ 7   Changed 7 months ago by cebif

Replying to cebif:

Replying to tqh:

So when you corrected that it works correctly?

Yes, I have retested with corrections to UserSetupEnvironment and it has not crashed at startup.

I spoke too soon. It is still crashing. It just needed some more tests to find out; after I started Firefox from first booting Haiku this morning.

  Changed 7 months ago by cebif

It is still crashing (not everytime) even with the UserSetupEnvironment from Bebits directly copied here without any alteration, to show the literal path.

  Changed 7 months ago by tqh

Same type of backtrace?

  Changed 6 months ago by cebif

I have tested again in r24577, I mean many repeat tests and it is not crashing.

  Changed 4 months ago by cebif

I must have made an error with the haiku version number I reported testing with in my last comment. It cannot have been r24577 because that is an earlier version than the version I first reported the bug with. The actual version must have been r25477 because I keep the last few images that I have used in a folder and that is the closest match, with the same numbers but the 4 and 5 reversed. It is also about the same time as I made that comment. In any case I am now testing with r26493 and cannot reproduce the bug anymore.

  Changed 2 months ago by axeld

  • status changed from new to closed
  • resolution set to fixed

So I'm cautiously closing this bug. Please reopen if it happens again.

  Changed 6 weeks ago by luroh

  • status changed from closed to reopened
  • resolution fixed deleted

Rev 28144, fresh build, booted fine in Vmware Player, started Firefox -> panic.
This has happened to me occasionally in the past as well, but I've never managed to catch the serial output before.
serial.txt attached.

  Changed 6 weeks ago by luroh

Ugh, Trac's acting up. File available at http://81.26.233.149/files/28144_serial.txt

  Changed 6 weeks ago by tqh

Seems to be a deadbeef on freeing a socket here: 12 92007d24 (+ 80) 800b0fdf <kernel_x86>:list_remove_link + 0x000b 13 92007d74 (+ 48) 800b1122 <kernel_x86>:list_remove_head_item + 0x001a 14 92007da4 (+ 48) 80555021 </boot/beos/system/add-ons/kernel/network/stack> delete_children(list*: 0x90c11960) + 0x0021 15 92007dd4 (+ 64) 80555c22 </boot/beos/system/add-ons/kernel/network/stack> socket_delete(net_socket*: 0x90c117f8) + 0x008e

It seems that keeps popping up once in a while.

Here is the Firefox side of things: http://mxr.mozilla.org/mozilla1.8.0/source/nsprpub/pr/src/io/prpolevt.c#413 I think I'll rewrite that as it may be optimized AF_UNIX(?) for Haiku and may be fragile under BeOS.

Note: See TracTickets for help on using tickets.