856138 - Elizabeth and Evan's Engagement Crashes Nightly

Status: RESOLVED WORKSFORME

(Core :: Widget: Cocoa, defect)

Description

[Bobby Holley (:bholley)]

There appears to be some infinite recursion going on. We should get to the bottom of this, otherwise they may have to call off the wedding. ;-)

Waldo says this doesn't reproduce on his linux box.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20130329 Firefox/22.0 ID:20130329030904 CSet: 8693d1d4c86d

I've also reproduced this in a local debug build. I'll attach a stack.

Comment 1

[Bobby Holley (:bholley)]

Attachment: debug spew + stack

Comment 2

[Boris Zbarsky [:bzbarsky]]

> nsRunnableMethodImpl

Can you tell which method it's running?

Comment 3

[Bobby Holley (:bholley)]

(In reply to Boris Zbarsky (:bz) from comment #2)
> > nsRunnableMethodImpl
> 
> Can you tell which method it's running?

From the stack, it appears to be nsThreadPool::ShutdownThread:

http://mxr.mozilla.org/mozilla-central/source/xpcom/threads/nsThreadPool.cpp#121

nsThread::Shutdown spins the event loop on the main thread until it receives a message from the thread it's waiting to shut down. Given the infinite recursion, that appears to be getting stuck somehow going in and out of Cocoa stuff.

Comment 4

[Benjamin Smedberg]

How many threads are there in this threadpool? It appears to me at first glance that this is not infinite recursion, just "as many threads as are in the threadpool" recursion. Do we know what about this website in particular might allow unbounded growth of the number of threads in a threadpool? Typically threadpools are limited to a fairly small set of threads, i.e. "# of cores".

http://mxr.mozilla.org/mozilla-central/ident?i=SetThreadLimit shows:

* stream transport service: 25 threads
* indexedDB: 20 threads
* async image decoding: std::max(PR_GetNumberOfProcessors() - 1, 1) (default) or the value of the pref "image.multithreaded_decoding.limit"

Most of these thread pools only go away at shutdown, in which case spinning the event loop doesn't enter widget code, and so it's likely that they use much less stack space. So I strongly suspect the indexeddb threadpool here, especially if this website makes use of indexeddb.

We can and probably should solve this by adding an nsThread::AsyncShutdown method and waiting for all of the threads to shut down with a single event loop. But I'm not exactly sure how to do that, because threadpools appear to have this strange behavior of dispatching an event from the pool thread to call nsThread::Shutdown on itself. I think that happens because threadpool threads are "XPCOM threads" and they expire themselves. But it's strange that these are XPCOM threads, because they don't process events in the normal way and could probably just be joinable NSPR threads.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Sure hope they didn't hold off on the wedding on our account ;)

This doesn't reproduce for me on Windows. I tried both the Fx22 release build and a current nightly. Bobby, all good on your end too?

Comment 7

[Bobby Holley (:bholley)]

No crashes for me on 43.0a2.

They went ahead with the wedding, and a re-spin has yet to be deemed necessary. ;-)

Comment 8

[Ryan VanderMeulen [:RyanVM]]

*whew* that's a relief! :)