527847 - Electrolysis: nsAppShell dying (mach_msg_trap()) in the subprocess

Status: RESOLVED WORKSFORME

(Core :: IPC, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Backtrace:

#0  0x9134e286 in mach_msg_trap ()
#1  0x91355a7c in mach_msg ()
#2  0x91372ce9 in vm_deallocate ()
#3  0x956d07d1 in FlattenedCFItem::~FlattenedCFItem ()
#4  0x95673500 in _LSApplicationCheckIn ()
#5  0x97427614 in GetOurExecutableCheckinInformation ()
#6  0x973f4749 in _RegisterApplication ()
#7  0x973f45ea in GetCurrentProcess ()
#8  0x95fe4138 in GetSystemUIMode ()
#9  0x95fe40e7 in IsMenuBarVisible ()
#10 0x9697f419 in _NSInitializeAppContext ()
#11 0x9697eda0 in -[NSApplication init] ()
#12 0x9697e7b1 in +[NSApplication sharedApplication] ()
#13 0x043ac8aa in nsAppShell::Init (this=0x8659a0) at /Users/cjones/mozilla/electrolysis/widget/src/cocoa/nsAppShell.mm:326
#14 0x043d48a7 in nsAppShellInit (module=0x80f4a0) at ../xpwidgets/nsAppShellSingleton.h:74
#15 0x04586e90 in nsGenericModule::Initialize (this=0x80f4a0, compMgr=0x813110) at nsGenericFactory.cpp:273
#16 0x045870a7 in nsGenericModule::GetClassObject (this=0x80f4a0, aCompMgr=0x813110, aClass=@0x683fe38, aIID=@0x48e9df4, r_classObj=0x683fe50) at nsGenericFactory.cpp:361
#17 0x045e6d07 in nsFactoryEntry::GetFactory (this=0x683fe38, aFactory=0xb0102ba0) at /Users/cjones/mozilla/electrolysis/xpcom/components/nsComponentManager.cpp:3685
#18 0x045e706e in nsComponentManagerImpl::CreateInstance (this=0x813110, aClass=@0x48f1aa4, aDelegate=0x0, aIID=@0x48e9f04, aResult=0xb0102c04) at /Users/cjones/mozilla/electrolysis/xpcom/components/nsComponentManager.cpp:1593
#19 0x045e9866 in nsComponentManagerImpl::GetService (this=0x813110, aClass=@0x48f1aa4, aIID=@0x48e9f04, result=0xb0102cfc) at /Users/cjones/mozilla/electrolysis/xpcom/components/nsComponentManager.cpp:1901
#20 0x0457929b in CallGetService (aCID=@0x48f1aa4, aIID=@0x48e9f04, aResult=0xb0102cfc) at nsComponentManagerUtils.cpp:83
#21 0x0457979c in nsGetServiceByCID::operator() (this=0xb0102d14, aIID=@0x48e9f04, aInstancePtr=0xb0102cfc) at nsComponentManagerUtils.cpp:256
#22 0x04564680 in nsCOMPtr<nsIAppShell>::assign_from_gs_cid (this=0xb0102d6c, gs={mCID = @0x48f1aa4}, aIID=@0x48e9f04) at nsCOMPtr.h:1209
#23 0x045646da in nsCOMPtr<nsIAppShell>::nsCOMPtr (this=0xb0102d6c, gs={mCID = @0x48f1aa4}) at nsCOMPtr.h:588
#24 0x032ee319 in XRE_RunAppShell () at /Users/cjones/mozilla/electrolysis/toolkit/xre/nsEmbedFunctions.cpp:443
#25 0x044ad85f in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x811ce0, aDelegate=0xb0102e44) at /Users/cjones/mozilla/electrolysis/ipc/glue/MessagePump.cpp:194
#26 0x044dc546 in MessageLoop::RunInternal (this=0xb0102e44) at /Users/cjones/mozilla/electrolysis/ipc/chromium/src/base/message_loop.cc:211
#27 0x044dc55d in MessageLoop::RunHandler (this=0xb0102e44) at /Users/cjones/mozilla/electrolysis/ipc/chromium/src/base/message_loop.cc:194
#28 0x044dc5c1 in MessageLoop::Run (this=0xb0102e44) at /Users/cjones/mozilla/electrolysis/ipc/chromium/src/base/message_loop.cc:168
#29 0x0450070b in base::Thread::ThreadMain (this=0x80f448) at /Users/cjones/mozilla/electrolysis/ipc/chromium/src/base/thread.cc:165
#30 0x0452fdc4 in ThreadFunc (closure=0x80f448) at /Users/cjones/mozilla/electrolysis/ipc/chromium/src/base/platform_thread_posix.cc:26
#31 0x9137f155 in _pthread_start ()
#32 0x9137f012 in thread_start ()

It runs fine in the parent process, so I'm guessing it's something with Cocoa-threading related, as this code isn't running on the "main" thread in the child process.

This appears to be the only thing blocking IPDL unit tests passing on OS X, as all the IPC code works fine --- just the Messages posted to the child's XPCOM thread get dropped because of this error, and no progress is made.

Comment 1

[Steven Michaud [:smichaud] (Retired)]

> as this code isn't running on the "main" thread in the child process

Any way to make it run on the main thread?

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Yes, but it requires some pain.  Thanks for taking a look!

Comment 3

[Steven Michaud [:smichaud] (Retired)]

It's entirely possible you won't be able to call nsAppShell::Init() on
anything but the main thread ... but I don't know that for sure.

However, it may be that only parts of nsAppShell::Init() need to run
on the main thread.  So I suggest going through it line by line, in an
attempt to find out what those parts might be.

From your stack, it looks like the hang is taking place at the
following call:

+[NSApplication sharedApplication]

It's possible the first call to this method needs to run on the main
thread.  So I suggest ensuring this first gets called on the main
thread, before trying to call nsAppShell::Init() on a secondary
thread.

Even if this works, nsAppShell::Init() may hang or barf on a later
line (when called on a secondary thread).  If so, try repeating the
same strategy -- try first making the call (the one that barfs or
hangs) on the main thread.

With luck, after several iterations you'll end up with a way to call
nsAppShell::Init() (or parts of it) on a secondary thread.

Comment 4

[Doug Turner (:dougt)]

not seeing this.  maybe the puppet widgets made this go away.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

I thought the patch for bug 528146 had fixed this.

Is that what you mean by "puppet widgets"?