Bug 65604 - Crash in RefPtr.h (in Webkit 533.3 shipped with Qt 4.7.3, git checkout)
Summary: Crash in RefPtr.h (in Webkit 533.3 shipped with Qt 4.7.3, git checkout)
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 525.x (Safari 3.2)
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-03 04:15 PDT by pvonnied
Modified: 2012-01-26 03:54 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pvonnied 2011-08-03 04:15:17 PDT
After fast reloading of some custom JavaScript code, the Qt runtime is terminated by a segfault
caused in the member function "bool operator!() const { return !m_ptr; }" of class RefPtr.h.

In the strack trace below, the class PartScreen is a subclass of QWebView which loads the custom
JavaScript code.

Stack trace:

Thread [1] 5326 [core: 1] (Suspended : Signal : SIGSEGV:Segmentation fault)	
	WTF::RefPtr<WebCore::StringImpl>::operator!() at RefPtr.h:66 0x7ffff663433c	
	WebCore::String::isEmpty() at String.cpp:608 0x7ffff6b317ba	
	WebCore::KURL::isEmpty() at KURL.h:327 0x7ffff669cf88	
	WebCore::FrameLoader::setEncoding() at FrameLoader.cpp:1,484 0x7ffff6a193c9	
	WebCore::FrameLoaderClientQt::dispatchDidFailLoading() at FrameLoaderClientQt.cpp:904 0x7ffff6cd3849	
	WebCore::ResourceLoadNotifier::didFailToLoad() at ResourceLoadNotifier.cpp:98 0x7ffff6a4a7c8	
	WebCore::ResourceLoader::didCancel() at ResourceLoader.cpp:345 0x7ffff6a4997d	
	WebCore::MainResourceLoader::didCancel() at MainResourceLoader.cpp:105 0x7ffff6a3df43	
	WebCore::ResourceLoader::cancel() at ResourceLoader.cpp:362 0x7ffff6a49a88	
	WebCore::ResourceLoader::cancel() at ResourceLoader.cpp:352 0x7ffff6a499cf	
	WebCore::DocumentLoader::stopLoading() at DocumentLoader.cpp:232 0x7ffff6a08b08	
	WebCore::FrameLoader::stopAllLoaders() at FrameLoader.cpp:2,323 0x7ffff6a1cde1	
	WebCore::FrameLoader::continueLoadAfterNavigationPolicy() at FrameLoader.cpp:3,511 0x7ffff6a2163c	
	WebCore::FrameLoader::callContinueLoadAfterNavigationPolicy() at FrameLoader.cpp:3,468 0x7ffff6a213fc	
	WebCore::PolicyCallback::call() at PolicyCallback.cpp:101 0x7ffff6a42db1	
	WebCore::PolicyChecker::continueAfterNavigationPolicy() at PolicyChecker.cpp:160 0x7ffff6a43dd3	
	WebCore::FrameLoaderClientQt::callPolicyFunction() at FrameLoaderClientQt.cpp:192 0x7ffff6cd08c4	
	WebCore::FrameLoaderClientQt::dispatchDecidePolicyForNavigationAction() at FrameLoaderClientQt.cpp:1,035 0x7ffff6cd4850	
	WebCore::PolicyChecker::checkNavigationPolicy() at PolicyChecker.cpp:88 0x7ffff6a436da	
	WebCore::FrameLoader::loadWithDocumentLoader() at FrameLoader.cpp:2,102 0x7ffff6a1bf02	
	WebCore::FrameLoader::load() at FrameLoader.cpp:2,056 0x7ffff6a1baac	
	WebCore::FrameLoader::load() at FrameLoader.cpp:1,997 0x7ffff6a1b40d	
	WebCore::FrameLoader::load() at FrameLoader.cpp:1,984 0x7ffff6a1b1f4	
	QWebFrame::load() at qwebframe.cpp:950 0x7ffff6cdcaaa	
	QWebFrame::load() at qwebframe.cpp:894 0x7ffff6cdc612	
	QWebView::load() at qwebview.cpp:432 0x7ffff6cf7201	
	PartScreen::UpdateContent() at PartScreen.cpp:62 0x4784c9	
	<...more frames...>
Comment 1 Julien Chaffraix 2011-09-08 07:57:00 PDT
The best way to get this fixed would be to bundle a page / Qt application that shows the problem. Without that, it is a shot in the dark for anyone who want to look at this bug.
Comment 2 Dave Butler 2012-01-10 19:58:06 PST
I am getting a similar stack trace, I am using pyside to render some google docs presentations...


#0  0xb4293eec in WTF::RefPtr<WebCore::StringImpl>::operator! (this=0x144) at ../JavaScriptCore/wtf/RefPtr.h:66
#1  0xb46a3caf in WebCore::String::isEmpty (this=0x144) at platform/text/String.cpp:608
#2  0xb42f027d in WebCore::KURL::isEmpty (this=0x144) at platform/KURL.h:327
#3  0xb45c18a8 in WebCore::FrameLoader::setEncoding (this=0x0, name=..., userChosen=false) at loader/FrameLoader.cpp:1484
#4  0xb4806b9d in WebCore::FrameLoaderClientQt::dispatchDidFailLoading (this=0x9ec8740, loader=0xae270a00, identifier=16, error=...) at ../WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp:904
#5  0xb45e8e9e in WebCore::ResourceLoadNotifier::didFailToLoad (this=0xacd4678c, loader=0xacd24000, error=...) at loader/ResourceLoadNotifier.cpp:98
#6  0xb45e8263 in WebCore::ResourceLoader::didCancel (this=0xacd24000, error=...) at loader/ResourceLoader.cpp:345
#7  0xb45e9e82 in WebCore::SubresourceLoader::didCancel (this=0xacd24000, error=...) at loader/SubresourceLoader.cpp:234
#8  0xb45e8328 in WebCore::ResourceLoader::cancel (this=0xacd24000, error=...) at loader/ResourceLoader.cpp:362
#9  0xb45e82a7 in WebCore::ResourceLoader::cancel (this=0xacd24000) at loader/ResourceLoader.cpp:352
#10 0xb45ba2dc in WebCore::DocumentThreadableLoader::cancel (this=0xae280500) at loader/DocumentThreadableLoader.cpp:158
#11 0xb47b5179 in WebCore::XMLHttpRequest::internalAbort (this=0xac88e540) at xml/XMLHttpRequest.cpp:600
#12 0xb47b6d0f in WebCore::XMLHttpRequest::stop (this=0xac88e540) at xml/XMLHttpRequest.cpp:979
#13 0xb4472bcf in WebCore::ScriptExecutionContext::stopActiveDOMObjects (this=0xaca05830) at dom/ScriptExecutionContext.cpp:226
#14 0xb441cb8a in WebCore::Document::detach (this=0xaca05800) at dom/Document.cpp:1518
#15 0xb46286f2 in WebCore::Frame::setView (this=0xacd46680, view=...) at page/Frame.cpp:256
#16 0xb45c6a30 in WebCore::FrameLoader::closeAndRemoveChild (this=0xae213130, child=0xacd46680) at loader/FrameLoader.cpp:3109
#17 0xb45c6f29 in WebCore::FrameLoader::detachFromParent (this=0xacd466b0) at loader/FrameLoader.cpp:3198
#18 0xb45c69cf in WebCore::FrameLoader::detachChildren (this=0xae213130) at loader/FrameLoader.cpp:3101
#19 0xb45c6eaa in WebCore::FrameLoader::detachFromParent (this=0xae213130) at loader/FrameLoader.cpp:3188

My code is way too huge (and mostly written in python...) to easily create a test case for this...   perhaps we can find something that we are doing that is shared between our applications... I seem to only get this problem when I have been loading from cache, (offline mode...) and then coming back online
Comment 3 Julien Chaffraix 2012-01-11 01:02:26 PST
#3  0xb45c18a8 in WebCore::FrameLoader::setEncoding (this=0x0, name=..., userChosen=false) at loader/FrameLoader.cpp:1484
#4  0xb4806b9d in WebCore::FrameLoaderClientQt::dispatchDidFailLoading (this=0x9ec8740, loader=0xae270a00, identifier=16, error=...) at ../WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp:904

It looks like the FrameLoader pointer is NULL here. CC'ing Simon in case he knows what is going on.
Comment 4 pvonnied 2012-01-26 03:54:42 PST
(In reply to comment #2)
> I am getting a similar stack trace, I am using pyside to render some google docs presentations...
> 
> 
> #0  0xb4293eec in WTF::RefPtr<WebCore::StringImpl>::operator! (this=0x144) at ../JavaScriptCore/wtf/RefPtr.h:66
> #1  0xb46a3caf in WebCore::String::isEmpty (this=0x144) at platform/text/String.cpp:608
> #2  0xb42f027d in WebCore::KURL::isEmpty (this=0x144) at platform/KURL.h:327
> #3  0xb45c18a8 in WebCore::FrameLoader::setEncoding (this=0x0, name=..., userChosen=false) at loader/FrameLoader.cpp:1484
> #4  0xb4806b9d in WebCore::FrameLoaderClientQt::dispatchDidFailLoading (this=0x9ec8740, loader=0xae270a00, identifier=16, error=...) at ../WebKit/qt/WebCoreSupport/FrameLoaderClientQt.cpp:904
> #5  0xb45e8e9e in WebCore::ResourceLoadNotifier::didFailToLoad (this=0xacd4678c, loader=0xacd24000, error=...) at loader/ResourceLoadNotifier.cpp:98
> #6  0xb45e8263 in WebCore::ResourceLoader::didCancel (this=0xacd24000, error=...) at loader/ResourceLoader.cpp:345
> #7  0xb45e9e82 in WebCore::SubresourceLoader::didCancel (this=0xacd24000, error=...) at loader/SubresourceLoader.cpp:234
> #8  0xb45e8328 in WebCore::ResourceLoader::cancel (this=0xacd24000, error=...) at loader/ResourceLoader.cpp:362
> #9  0xb45e82a7 in WebCore::ResourceLoader::cancel (this=0xacd24000) at loader/ResourceLoader.cpp:352
> #10 0xb45ba2dc in WebCore::DocumentThreadableLoader::cancel (this=0xae280500) at loader/DocumentThreadableLoader.cpp:158
> #11 0xb47b5179 in WebCore::XMLHttpRequest::internalAbort (this=0xac88e540) at xml/XMLHttpRequest.cpp:600
> #12 0xb47b6d0f in WebCore::XMLHttpRequest::stop (this=0xac88e540) at xml/XMLHttpRequest.cpp:979
> #13 0xb4472bcf in WebCore::ScriptExecutionContext::stopActiveDOMObjects (this=0xaca05830) at dom/ScriptExecutionContext.cpp:226
> #14 0xb441cb8a in WebCore::Document::detach (this=0xaca05800) at dom/Document.cpp:1518
> #15 0xb46286f2 in WebCore::Frame::setView (this=0xacd46680, view=...) at page/Frame.cpp:256
> #16 0xb45c6a30 in WebCore::FrameLoader::closeAndRemoveChild (this=0xae213130, child=0xacd46680) at loader/FrameLoader.cpp:3109
> #17 0xb45c6f29 in WebCore::FrameLoader::detachFromParent (this=0xacd466b0) at loader/FrameLoader.cpp:3198
> #18 0xb45c69cf in WebCore::FrameLoader::detachChildren (this=0xae213130) at loader/FrameLoader.cpp:3101
> #19 0xb45c6eaa in WebCore::FrameLoader::detachFromParent (this=0xae213130) at loader/FrameLoader.cpp:3188
> 
> My code is way too huge (and mostly written in python...) to easily create a test case for this...   perhaps we can find something that we are doing that is shared between our applications... I seem to only get this problem when I have been loading from cache, (offline mode...) and then coming back online

Our application is working in offline mode only (cache). What we are doing is building up an HTML UI that is reloaded after every interaction. That's one common thing. Our code is also too complex to just isolate some parts for testing.