[webkit-dev] Stability problems involving Javascript GC

[Chris Backas]

Hi Geoff,

On Dec 6, 2010, at 2:24 PM, Geoffrey Garen wrote:

> Hi Chris.
>
>> (function () {
>> 		var app = document.getElementById(\"RemoteApplication\");
>> 		var ReturnMe = Number(app.getListenPort());
>> 		app = null;
>> 		return ReturnMe;
>> 		})()
>
> FYI, from a GC perspective, there's no need to set "app" to null in  
> the snippet above.

Indeed, I didn't think it would. That and the Number() wrap were just  
grasping at straws.

>> And here is a common sort of stack trace I'm getting (this one from  
>> 10.6)
>> Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
>> 0   com.apple.JavaScriptCore      	0x9489f766 WTF::fastFree(void*)  
>> + 134
>> 1   com.apple.WebCore             	0x929be825  
>> WebCore::CSSSelectorList::deleteSelectors() + 389
>> 2   com.apple.WebCore             	0x92a38269  
>> WebCore::CSSStyleRule::~CSSStyleRule() + 57
>> 3   com.apple.WebCore             	0x929c3a04  
>> WTF::Vector<WTF::RefPtr<WebCore::StyleBase>, 0ul>::shrink(unsigned  
>> long) + 84
>> 4   com.apple.WebCore             	0x92a38193  
>> WebCore::StyleSheet::~StyleSheet() + 179
>> 5   com.apple.WebCore             	0x92a38066  
>> WebCore::CSSStyleSheet::~CSSStyleSheet() + 102
>> 6   com.apple.WebCore             	0x92a91074  
>> WTF::Vector<WTF::RefPtr<WebCore::StyleSheet>, 0ul>::shrink(unsigned  
>> long) + 84
>> 7   com.apple.WebCore             	0x92a29243  
>> WebCore::StyleSheetList::~StyleSheetList() + 67
>> 8   com.apple.WebCore             	0x92a28cd9  
>> WebCore::Document::~Document() + 3529
>> 9   com.apple.WebCore             	0x92a27f01  
>> WebCore::HTMLDocument::~HTMLDocument() + 129
>> 10  com.apple.WebCore             	0x92a27def  
>> WebCore::Node::~Node() + 431
>> 11  com.apple.WebCore             	0x92c05a21  
>> WebCore::HTMLIFrameElement::~HTMLIFrameElement() + 129
>> 12  com.apple.WebCore             	0x92b356fe  
>> WebCore::JSNode::~JSNode() + 382
>> 13  com.apple.JavaScriptCore      	0x9495a0d2 JSC::Heap::sweep() +  
>> 274
>>
>> I find it odd that main isn't seen in the stack, but it never is.
>
>> The crash nearly ALWAYS occurs in WTF::fastFree(), very  
>> occasionally occurring instead in some other memory management  
>> function.
>
> In the backtrace you've pasted, there's no direct link to JavaScript  
> GC. GC only appears in the backtrace because a JavaScript object  
> held the last reference to the DOM document object.

Ah, maybe I jumped to conclusions then. Since adding the above- 
mentioned snippet of Javascript is the ONLY difference between perfect  
stability and constant crashing after the first iteration my theory  
was that *something* left over somehow from that JS was the problem.

> There's a small chance that you've run into this bug, or one of its  
> relations: https://bugs.webkit.org/show_bug.cgi?id=50165.
>
> The best way to diagnose this is to provide a sample application  
> that demonstrates the crash in Bugzilla.

Unfortunately I wouldn't be able to submit a reproduction case based  
on this web app/applet, they're both private resources of a business  
partner or ours that we're attempting to automate interaction with.

However, you did give me another idea of something to try. Are there  
instructions anywhere for building a WebKit nightly and then embedding  
it inside your application? This is an application for internal use  
only, so we have no problem with requiring a special build if that  
helps.

Thanks for the reply,
-Chris Backas




CONFIDENTIALITY NOTICE: This email (and any related attachments) contains information from InfoPlus (a service of Bristol Capital, Inc.).  It is intended only for the addressee and may contain information that is confidential and/or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or are acting as agent for the intended recipient, any use or disclosure of this communication is prohibited. If you have received this communication in error, please notify me immediately to arrange for the appropriate method of returning or disposing of the communication. If our respective Companies have confidentiality provisions in effect, this email and the materials contained herein are deemed CONFIDENTIAL and should be treated accordingly unless expressly provided otherwise.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20101206/0b05ae73/attachment.html>