Closed Bug 337481 Opened 18 years ago Closed 18 years ago

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


(Core :: Layout, defect)

Not set





(Reporter: jaas, Assigned: mark)




(2 files)

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.
Attached file startup crash trace
Blocks: 326469
Attachment #221614 - Attachment is patch: false
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.
Attached file Apple crash log
Crash log for comment 2
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?
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.
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

if (mProcessingNextNativeEvent)
used to be
if (mRunWasCalled)

appears related
More notes in bug 337550 comment 17.
Severity: major → blocker
FWIW, the SeaMonkey 2006-05-13-01 build from <> did work for me without any problems under OS X 10.4.6/PPC.
(In reply to comment #10)
> FWIW, the SeaMonkey 2006-05-13-01 build from
> <>
> 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
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.
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.
see also bug 337481 which is for the non-cocoa widgets version of this crash.
*** Bug 338329 has been marked as a duplicate of this bug. ***
Not cocoa-specific.  I'm putting this into layout because that's where the crash is.
No longer blocks: 326469
Component: Widget: Cocoa → Layout
Fixed by checkin of bug 331117.
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.