Re: [webkit-dev] Stability problems involving Javascript GC
On Dec 19, 2010, at 4:24 PM, David Kilzer wrote: On Dec 17, 2010, at 12:02 AM, Zoltan Herczeg wrote: On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u- szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. In addition to valgrind, try running the test under guard malloc on Mac OS X with system malloc enabled. See man libgmalloc: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/libgmalloc.3.html%23//apple_ref/doc/man/3/libgmalloc Dave Thanks for the suggestion. I had tried this with guard malloc, and although it took something like 10x longer to run my tests, it didn't reveal anything more interesting. In the end, I ran out of time to truly solve the problem, and instead isolated the WebKit portion into a separate process. That way it can crash all it likes without affecting the host application which had a 100% uptime requirement. Ironically, it now never crashes at all because I run it once, do what needs to be done, and kill the child process. The bug only ever crashed on multiple executions. -Chris 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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
On Dec 17, 2010, at 12:02 AM, Zoltan Herczeg wrote: On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. In addition to valgrind, try running the test under guard malloc on Mac OS X with system malloc enabled. See man libgmalloc: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/libgmalloc.3.html%23//apple_ref/doc/man/3/libgmalloc Dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
I haven't received your reply before. To capture this bug, you have to disable fastmalloc, and use the internal (trackable) memory allocator replacement of valgrind. Run build-webkit --system-malloc This will redirect all allocations to the system malloc. Thanks. That's a good point. I already tested the system without fast-malloc, but it didn't reproduce the crash in that configuration so I didn't thought of valgrinding it. I'll give it a try Cheers -- Samuel Rivas RD and Base Development Leader m:+34 619 92 77 46 t:+34 981 17 33 44 ext:61 www.lambdastream.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
It is possible to add macros to the code to help valgrind know which areas are being used by a custom allocator. (See VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.) I'm not sure if they're useful in this situation, but they're worth taking a look at. I see. That would discover errors such as something overwriting structures allocated by the allocator but that were not handled to the application, right? Is there any reason why that's not included in the webkit allocator? I mean apart from lack of time/interest, of course. Regards -- Samuel Rivas RD and Base Development Leader m:+34 619 92 77 46 t:+34 981 17 33 44 ext:61 www.lambdastream.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
It is possible to add macros to the code to help valgrind know which areas are being used by a custom allocator. (See VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.) I'm not sure if they're useful in this situation, but they're worth taking a look at. I see. That would discover errors such as something overwriting structures allocated by the allocator but that were not handled to the application, right? Is there any reason why that's not included in the webkit allocator? I mean apart from lack of time/interest, of course. I don't think that would be useful. Real allocators do several optimizations, which could hide many errors. An example: p = malloc(100); free(p); p = malloc(100); I clever allocator would probably return with the same pointer. However, valgrind wants to detect unintended access to freed blocks, so its allocator would never reuse the same address if possible. Moreover, it skips X bytes before and after the block to detect overwrite / underwrite situations (red zones). Thus, we should use the system malloc if possible (captured and redirected by valgrind). And leave that macro to those cases, where the software is designed to not use system malloc (garbage collected memory areas for example). Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. Regards -- Samuel Rivas RD and Base Development Leader m:+34 619 92 77 46 t:+34 981 17 33 44 ext:61 www.lambdastream.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
-Original Message- From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev- boun...@lists.webkit.org] On Behalf Of Samuel Rivas Sent: Thursday, December 16, 2010 3:03 AM To: Zoltan Herczeg Cc: webkit-dev Development Subject: Re: [webkit-dev] Stability problems involving Javascript GC On 6 December 2010 22:31, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: Crash in WTF::fastMalloc? Such things only happen if something overwrites memory areas belongs to the memory manager (i.e overwrites some bytes before or after a block returned by malloc). Try some valgrind equivalent on mac to detect those writings into red zones. How can you use valgrind to help on that? We had some symptoms similar to this and also came to the conclusion that probably something is overwriting the structures used by fast malloc, but couldn't find anything with valgrind. Overwriting in an area that has bee reserved is not an error vangrind finds, at least not with any options that I know. It is possible to add macros to the code to help valgrind know which areas are being used by a custom allocator. (See VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK, for example.) I'm not sure if they're useful in this situation, but they're worth taking a look at. Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Stability problems involving Javascript GC
Hello all,
I'm trying to write a Cocoa application with embedded WebViews that
navigates through a web application, eventually arriving at a page
with a Java applet. I query some values from the Java applet via
Javascript, and then at some point I close up and free the WebView.
The problem is that my program is quite unstable, and crashes at
random points during the navigation process anywhere from the 2nd to
7th time I use it. I create an entirely new WebView for each attempt.
I'll attach a typical backtrace below.
Anyway, using basic troubleshooting techniques I believe I've narrowed
the instability down to querying the Java applet through LiveConnect -
testing the process with 100 iterations up to but NOT including the
page with the applet was perfectly stable. 50 tests going to the page
WITH the applet, but NOT querying it was also perfectly stable. As
soon as I make even a basic query through LiveConnect though, I
introduce instability.
The crashes always seems to be cause in a Javascript Core Garbage
Collection pass (see stack trace below), which leads me to thing that
I'm doing something best avoided in my interactions - like, perhaps
there's a dangling Javascript-Java proxy object where the Java peer
was destroyed. But, basically, I'm looking for any insight anyone
might have as to pitfalls that might not be obvious in this area.
Problem occurs on 10.5.8 + All latest updates, and 10.6.5 + All latest
updates. Java 6 on both platforms (required by the Applet) - using the
Out-of-Process plugin on 10.5 and the in-process 32bit Java 6 on 10.6
Here is an example of my JS code, executed by [[webView
windowScriptObject] evaluateWebScript:someJavaScript] on the main
thread. The element in 'app' is a Java applet, getListenPort() is a
Java method called via LiveConnect. I have two other scripts that are
very similar, varying only in the method called.
(function () {
var app = document.getElementById(\RemoteApplication\);
var ReturnMe = Number(app.getListenPort());
app = null;
return ReturnMe;
})()
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.JavaScriptCore0x9489f766 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::VectorWTF::RefPtrWebCore::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::VectorWTF::RefPtrWebCore::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.JavaScriptCore0x9495a0d2 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.
Any insight on where to look to further track this down would be
greatly appreciated.
-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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
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.
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::VectorWTF::RefPtrWebCore::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::VectorWTF::RefPtrWebCore::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.
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.
Thanks,
Geoff___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Stability problems involving Javascript GC
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.WebCore0x929be825
WebCore::CSSSelectorList::deleteSelectors() + 389
2 com.apple.WebCore0x92a38269
WebCore::CSSStyleRule::~CSSStyleRule() + 57
3 com.apple.WebCore0x929c3a04
WTF::VectorWTF::RefPtrWebCore::StyleBase, 0ul::shrink(unsigned
long) + 84
4 com.apple.WebCore0x92a38193
WebCore::StyleSheet::~StyleSheet() + 179
5 com.apple.WebCore0x92a38066
WebCore::CSSStyleSheet::~CSSStyleSheet() + 102
6 com.apple.WebCore0x92a91074
WTF::VectorWTF::RefPtrWebCore::StyleSheet, 0ul::shrink(unsigned
long) + 84
7 com.apple.WebCore0x92a29243
WebCore::StyleSheetList::~StyleSheetList() + 67
8 com.apple.WebCore0x92a28cd9
WebCore::Document::~Document() + 3529
9 com.apple.WebCore0x92a27f01
WebCore::HTMLDocument::~HTMLDocument() + 129
10 com.apple.WebCore0x92a27def
WebCore::Node::~Node() + 431
11 com.apple.WebCore0x92c05a21
WebCore::HTMLIFrameElement::~HTMLIFrameElement() + 129
12 com.apple.WebCore0x92b356fe
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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
