Crash when running content shell with --single-process option

438 views
Skip to first unread message

Nathan Sobo

unread,
Apr 30, 2012, 6:32:42 PM4/30/12
to content-team
Hi. I'm exploring embedding chrome content module into my application,
but I don't want to fork subprocesses for rendering. I'd like to
render everything in the same process as the rest of my application
because I want to pass objects between the v8 execution contexts of
different windows and a global shared v8 context. I tried running the
content shell in single process mode, and it crashed. Is this not
finished yet?

Nathans-MacBook-Pro:Content Shell.app nathansobo$ Contents/MacOS/
Content\ Shell --single-process
objc[51599]: Object 0x6b887d10 of class NSPathStore2 autoreleased with
no pool in place - just leaking - break on objc_autoreleaseNoPool() to
debug
objc[51599]: Object 0x6b887e90 of class NSConcreteData autoreleased
with no pool in place - just leaking - break on
objc_autoreleaseNoPool() to debug
ASSERTION FAILED: m_thread == currentThread()
../../third_party/WebKit/Source/WebCore/platform/Timer.h(108) : bool
WebCore::TimerBase::isActive() const
1 0x283e33c WebCore::TimerBase::isActive() const
2 0x2838b12
WebCore::ScrollAnimatorMac::scrollbarPaintTimerIsActive() const
3 0x28386e0 -[ChromiumWebCoreObjCWebScrollbarPainterDelegate
setUpAlphaAnimation:scrollerPainter:part:animateAlphaTo:duration:]
4 0x2838e4a -[ChromiumWebCoreObjCWebScrollbarPainterDelegate
scrollerImp:animateKnobAlphaTo:duration:]
5 0x952b8d8c -[NSScrollerImp
setOverlayScrollerState:forceImmediately:]
6 0x952b8bae -[NSScrollerImpPair
_setOverlayScrollerState:forScrollerImp:forceImmediately:]
7 0x952d44a4 -[NSScrollerImpPair flashScrollers]
8 0x952d436e __-[NSScrollerImpPair
contentAreaWillDraw]_block_invoke_1
9 0x91b84e11 _dispatch_call_block_and_release
10 0x91b86da1 _dispatch_main_queue_callback_4CF
11 0x9972ffe3 __CFRunLoopRun
12 0x9972f47c CFRunLoopRunSpecific
13 0x9972f328 CFRunLoopRunInMode
14 0x9168f17f RunCurrentEventLoopInMode
15 0x916964e7 ReceiveNextEventCommon
16 0x91696356 BlockUntilNextEventMatchingListInMode
17 0x95181a9c _DPSNextEvent
18 0x95181306 -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:]
19 0x95455b17 -[NSApplication _realDoModalLoop:peek:]
20 0x95450c1d -[NSApplication _doModalLoop:peek:]
21 0x954556a4 -[NSApplication runModalForWindow:]
22 0x95445ab3 -[NSAlert runModal]
23 0x951b4528 __-[NSPersistentUIManager
promptToIgnorePersistentState]_block_invoke_1
24 0x95456174 -[NSApplication
_suppressFinishLaunchingFromEventHandlersWhilePerformingBlock:]
25 0x951b41e8 -[NSPersistentUIManager promptToIgnorePersistentState]
26 0x9518513a -[NSApplication
_reopenWindowsAsNecessaryIncludingRestorableState:registeringAsReady:completionHandler:]
27 0x9518507f -[NSApplication(NSAppleEventHandling)
_reopenWindowsIfNecessaryWithAppleEvent:completionHandler:]
28 0x95184f62 -[NSApplication(NSAppleEventHandling)
_handleAEOpenEvent:]
29 0x95184c8a -[NSApplication(NSAppleEventHandling)
_handleCoreEvent:withReplyEvent:]
30 0x99792298 -[NSObject performSelector:withObject:withObject:]
31 0x96fe70f6 __-[NSAppleEventManager
setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_1
Segmentation fault: 11

Avi Drissman

unread,
Apr 30, 2012, 6:36:33 PM4/30/12
to Nathan Sobo, content-team
Content Shell single process was something I never implemented. You're welcome to. Note that single process has never been supported in chrome, so expecting it to work at a level appropriate for release software isn't recommended. 

John Abd-El-Malek

unread,
Apr 30, 2012, 6:54:09 PM4/30/12
to Avi Drissman, Nathan Sobo, content-team
On Mon, Apr 30, 2012 at 3:36 PM, Avi Drissman <a...@google.com> wrote:
Content Shell single process was something I never implemented. You're welcome to. Note that single process has never been supported in chrome, so expecting it to work at a level appropriate for release software isn't recommended. 

That used to be the case, but now we are planning on using single process mode for Chrome on Android (for the WebView implementation).

Nathan Sobo

unread,
May 4, 2012, 12:29:38 AM5/4/12
to content-team
So due to the Android dependency, can single process now mode be
relied on to work correctly in production code? In any case, being
able to run the content shell in single process mode (at least in
development) would make debugging a lot more straightforward. Avi,
could you give me a rough explanation of what I'd need to change to
make it work? I'm new to Chromium, but I've been getting my bearings
in the last couple days. Thanks!

Avi Drissman

unread,
May 4, 2012, 8:42:16 AM5/4/12
to Nathan Sobo, content-team
I don't know. When I was bringing up content shell, it was just a repeated process of:

"hm, that's not behaving the way I thought"
"let's look to see how Chromium does things"
"oh, it looks like we need to do this initialization in content shell"
(copy it over)

The first thought that comes to mind is that if it's a threading issue, there might be some setup that Chromium does to set the right thread. OTOH, make sure that Chromium itself doesn't suffer the same issues in single-process mode. With your stack trace in particular, I know I've seen similar crashes in Chromium that looked like that.

Avi

John Abd-El-Malek

unread,
May 4, 2012, 1:48:17 PM5/4/12
to Nathan Sobo, content-team
On Thu, May 3, 2012 at 9:29 PM, Nathan Sobo <natha...@gmail.com> wrote:
So due to the Android dependency, can single process now mode be
relied on to work correctly in production code? In any case, being
able to run the content shell in single process mode (at least in
development) would make debugging a lot more straightforward.

This should work now mostly, but there are cases when deadlocks might happen, or some html5 features might not work (since we don't run the WebKit thread). This stuff is being worked on, but I don't have an estimate of when it'll be done.
Reply all
Reply to author
Forward
0 new messages