startup problems after nsIThreadManager landing [@ nsNodeInfo::GetNamespaceURI]

RESOLVED FIXED

Status

()

--
blocker
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: jaas, Assigned: mark)

Tracking

Trunk
PowerPC
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
Clean build of Cocoa Firefox on Mac OS X 10.4 (gcc4) after Darin's nsIThreadManager landing...

1. Delete profile (start fresh)
2. Launch Firefox

First of all, I can't click on any of the options in the import data window. After dismissing the window the browser just hangs with no windows and no menu bar. After quitting and relaunching the browser crashes on start.
(Reporter)

Comment 1

13 years ago
Created attachment 221614 [details]
startup crash trace
(Reporter)

Updated

13 years ago
Blocks: 326469

Comment 2

13 years ago
I crash pretty much the same way with a regular Tinderbox build (atlantia)
(fetched 20060511, 11::20am Japan Standard time) - time stamp on server was 10-May-2006 21:29.

Comment 3

13 years ago
Created attachment 221658 [details]
Apple crash log

Crash log for comment 2
(Reporter)

Comment 4

13 years ago
I get some feedback in the console about not being able to get the hidden window from the appshell. Did Darin's thread manager stuff change the timing of hidden window creation?
(Assignee)

Comment 5

13 years ago
My [broken?] appshell, I'll take.  See 337550.
Assignee: joshmoz → mark
Yesterday's (2006-05-11) and today's Firefox nightlies don't start up for me at all. I do get an icon on the dock, but when I click on it all I see is a default Application menu. No windows open, and the only way out is force quit. Restarting gives the same behavior again. I don't crash, though.
(Assignee)

Comment 7

13 years ago
Occurs with Carbon too, then.  Here's what I wrote on irc on the subject:

it may actually be a cross-plat issue but we're more susceptible to it on the mac because i have us running the native loop in a system routine

the other platforms retrieve and dispatch a single system event only once and then return

so if there's a case where something's not calling us away from the system loop, we'd get stuck because we go back to blocking waiting for a new system event after processing a system event until called away from the loop, where other platforms would be blocked by waiting for an event, and as soon as you moved the mouse or whatever, they'd process the system event and then return and let gecko events fire
(Assignee)

Comment 8

13 years ago
nsBaseAppShell:

if (mProcessingNextNativeEvent)
used to be
if (mRunWasCalled)

appears related
(Assignee)

Comment 9

13 years ago
More notes in bug 337550 comment 17.

Updated

13 years ago
Severity: major → blocker

Comment 10

13 years ago
FWIW, the SeaMonkey 2006-05-13-01 build from <http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/bm-xserve01-trunk/seamonkey-1.5a.en-US.mac.dmg> did work for me without any problems under OS X 10.4.6/PPC.

Comment 11

13 years ago
(In reply to comment #10)
> FWIW, the SeaMonkey 2006-05-13-01 build from
> <http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/bm-xserve01-trunk/seamonkey-1.5a.en-US.mac.dmg>
> did work for me without any problems under OS X 10.4.6/PPC.
> 

But it doesn't work on 10.3.9...
So the stack trace in comment 1 indicates that we're messing with the DOM after the layout module has shut down.  I believe Benjamin has a proposed patch to fix issues like that in bug 331117.
Depends on: 331117
(Assignee)

Comment 13

13 years ago
That's right.  This bug should really be about the stack traces in comment 1 and comment 3, and doesn't appear to be strictly related to the new threads manager or appshells at this point.  The other things I was talking about in this bug more properly belong in bug 337550.
(Assignee)

Updated

13 years ago
Summary: startup problems after nsIThreadManager landing → startup problems after nsIThreadManager landing [@ nsNodeInfo::GetNamespaceURI]
I crash with the same stack with a pretty standard (opt-with-symbols, no cocoa options) Firefox trunk build on 10.4.6 on x86, as of about 10 hours ago.  It is cramping my style something fierce, I must say.

Comment 15

13 years ago
see also bug 337481 which is for the non-cocoa widgets version of this crash.

Comment 16

13 years ago
*** Bug 338329 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 17

13 years ago
Not cocoa-specific.  I'm putting this into layout because that's where the crash is.
No longer blocks: 326469
Component: Widget: Cocoa → Layout
(Assignee)

Comment 18

13 years ago
Fixed by checkin of bug 331117.
(Assignee)

Updated

13 years ago
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.