Bug 31086 – Netscape plug-in that loads WebKit via Carbon API leads to crashes in Firefox

• Component: New Bugs
• Status: RESOLVED WONTFIX

[Steven Michaud]

For some time crashes at IdleTimerVector have been close to the top of
the Mozilla topcrasher list on OS X.  For example see http://crash-stats.mozilla.com/query/query?version=ALL%3AALL&platform=mac&date=&range_value=1&range_unit=weeks&query_search=signature&query_type=exact&query=&do_query=1.

IdleTimerVector (in the HIToolbox framework) is what's called by the
OS as a result of using InstallEventLoopIdleTimer()
(http://developer.apple.com/legacy/mac/library/documentation/Carbon/Reference/Carbon_Event_Manager_Ref/Reference/reference.html#//apple_ref/doc/uid/TP30000135-CH1g-CJBJCEJJ)
to install an "idle timer".

The Mozilla tree doesn't contain any calls to
InstallEventLoopIdleTimer().  But this *is* called by
DivXBrowserPlugin (http://www.divx.com/).  And 100% of the
IdleTimerVector crashes are associated with this module.

DivXBrowserPlugin is a Carbon app that uses WebKit.  There aren't too
many of these (DivXBrowserPlugin is the only one I can find).
Moreover it doesn't call InstallEventLoopIdleTimer() directly --
instead it calls WebInitForCarbon() (in the WebKit) and it's the
latter that calls InstallEventLoopIdleTimer().  The WebKit framework
is also 100% associated with the IdleTimerVector crashes.

(For information on the correlation of FF crashes with particular
modules, see the following links:
http://people.mozilla.org/~dbaron/crash-stats/20090929-interesting-modules
http://people.mozilla.com/crash_analysis/)

It turns out these crashes are caused by what happens in WebKit's
PoolCleaner() function -- the target of the "idle timer" installed by
WebInitForCarbon().  They should happen in any Cocoa browser that
loads a Carbon WebKit plugin, unless the browser takes certain
precautions (i.e. unless it does something to "disable"
PoolCleaner()).

The IdleTimerVector crashes don't happen on OS X 10.6 and above --
where PoolCleaner() is already disabled by changes to the Foundation
framework's NSPushAutoreleasePool() and NSPopAutoreleasePool()
functions.

This is discussed in much more detail at
https://bugzilla.mozilla.org/show_bug.cgi?id=509130.

I've proposed a patch there that works around the bug in Firefox.  And
Safari already works around the problem in a different way (see
https://bugzilla.mozilla.org/show_bug.cgi?id=509130#c42).

But it'd be nice to get this problem fixed at the source, in WebKit
code.

[Mark Rowe (bdash)]

(In reply to comment #0)
> DivXBrowserPlugin is a Carbon app that uses WebKit.  There aren't too
> many of these (DivXBrowserPlugin is the only one I can find).
> Moreover it doesn't call InstallEventLoopIdleTimer() directly --
> instead it calls WebInitForCarbon() (in the WebKit) and it's the
> latter that calls InstallEventLoopIdleTimer().  The WebKit framework
> is also 100% associated with the IdleTimerVector crashes.

To clarify things here as you’re mixing up terminology in a confusing manner:  DivXBrowserPlugin is a Netscape plug-in that happens to load and use WebKit via WebKit’s Carbon API.

> It turns out these crashes are caused by what happens in WebKit's
> PoolCleaner() function -- the target of the "idle timer" installed by
> WebInitForCarbon().  They should happen in any Cocoa browser that
> loads a Carbon WebKit plugin, unless the browser takes certain
> precautions (i.e. unless it does something to "disable"
> PoolCleaner()).

I’m not aware of any application, Safari or otherwise, that “disables” PoolCleaner, nor what that would even mean.

> This is discussed in much more detail at
> https://bugzilla.mozilla.org/show_bug.cgi?id=509130.
> 
> I've proposed a patch there that works around the bug in Firefox.  And
> Safari already works around the problem in a different way (see
> https://bugzilla.mozilla.org/show_bug.cgi?id=509130#c42).
> 
> But it'd be nice to get this problem fixed at the source, in WebKit
> code.

It’s not clear from your description what you think WebKit is doing incorrectly.  I’ve started reading through the Mozilla bug but there are many comments so it’ll take a little while for me to get up to speed.  A summary of what you think the issue is would be helpful.

[Steven Michaud]

> I’m not aware of any application, Safari or otherwise, that
> “disables” PoolCleaner, nor what that would even mean.

See particularly the comment in my patch
(https://bugzilla.mozilla.org/attachment.cgi?id=409942) and
https://bugzilla.mozilla.org/show_bug.cgi?id=509130#c42.

> A summary of what you think the issue is would be helpful.

I'll quote from my patch:

// The source-code for WebInitForCarbon() is in the WebKit source tree's
// WebKit/mac/Carbon/CarbonUtils.mm file.  Among other things it installs
// an idle timer on the main event loop, whose target is the PoolCleaner()
// function (also in CarbonUtils.mm).  WebInitForCarbon() allocates an
// NSAutoreleasePool object which it stores in the global sPool variable.
// PoolCleaner() periodically releases/drains sPool and creates another
// NSAutoreleasePool object to take its place.  The intention is to ensure
// an autorelease pool is in place for whatever Objective-C code may be
// called by WebKit code, and that it periodically gets "cleaned".  But
// PoolCleaner()'s periodic cleaning has a very bad effect on us -- it
// causes objects to be deleted prematurely, so that attempts to access them
// cause crashes.  This is probably because, when WebInitForCarbon() is
// called from a plugin in a Cocoa browser, one or more autorelease pools
// are already in place.  So, other things being equal, PoolCleaner() should
// have a similar effect on any Cocoa app that hosts a Carbon WebKit plugin.

It might be best to continue this discussion at
https://bugzilla.mozilla.org/show_bug.cgi?id=509130.  That's where all
the context is.

I just opened this bug to have the issue on record in the WebKit bug
database.  And also (of course) in the hope that you guys might find a
way to fix it :-)

[Mark Rowe (bdash)]

Retitling for sake of accuracy.

[Mark Rowe (bdash)]

<rdar://problem/7362667>

[Alexey Proskuryakov]

https://bugzilla.mozilla.org/show_bug.cgi?id=509130 is marked fixed, I guess we don't this need any more.