Bug 31658 - webkit_web_view_load_string() crash
: webkit_web_view_load_string() crash
Product: WebKit
Classification: Unclassified
Component: WebKit Gtk
: 528+ (Nightly build)
: PC Linux
: P2 Major
Assigned To: Nobody
Depends on:
  Show dependency treegraph
Reported: 2009-11-18 19:17 PST by Adrian Bunk
Modified: 2009-12-08 06:27 PST (History)
1 user (show)

See Also:

test program (1.60 KB, text/plain)
2009-11-18 19:17 PST, Adrian Bunk
no flags Details
work around (1.78 KB, patch)
2009-11-20 05:17 PST, Gustavo Noronha (kov)
oliver: review+
gns: commit‑queue-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Bunk 2009-11-18 19:17:05 PST
Created attachment 43478 [details]
test program

Download and compile the test program, and click twice on "Next Step".

- this bug is a serious problem for Liferea users
- the small example is not complete HTML, but the actual bug is with a complete XHTML file
- as seen in the test program, the same HTML is accepted in webkit_web_view_load_uri()
- tested on amd64 with 1.1.16 and latest SVN trunk
- --disable-jit does not help

$ gcc -g -O2 -Wall test-webkit-crash.c -o test-webkit-crash `pkg-config --cflags --libs gtk+-2.0 webkit-1.0`
$ ./test-webkit-crash
#0  0x00007f1fa2c9b4dd in __libc_waitpid (pid=12738, stat_loc=<value optimized out>, options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41
#1  0x00007f1fa2f69ed7 in IA__g_on_error_stack_trace (prg_name=0x40119e "test-webkit-crash") at /tmp/buildd/glib2.0-2.22.2/glib/gbacktrace.c:187
#2  0x0000000000400fbe in fatal_signal_handler (sig=<value optimized out>) at test-webkit-crash.c:36
#3  <signal handler called>
#4  IA__g_str_hash (v=0x0) at /tmp/buildd/glib2.0-2.22.2/glib/gstring.c:99
#5  0x00007f1fa2f7e28f in g_hash_table_lookup_node (hash_table=0x20ea770, key=0x0) at /tmp/buildd/glib2.0-2.22.2/glib/ghash.c:195
#6  IA__g_hash_table_lookup (hash_table=0x20ea770, key=0x0) at /tmp/buildd/glib2.0-2.22.2/glib/ghash.c:784
#7  0x00007f1fa504c334 in soup_cookie_jar_add_cookie (jar=0x20be360, cookie=0x2118760) at soup-cookie-jar.c:345
#8  0x00007f1fa62bf409 in WebCore::setCookies (url=<value optimized out>, value=...) at WebCore/platform/network/soup/CookieJarSoup.cpp:65
#9  0x00007f1fa5d9d10e in WebCore::Document::setCookie (this=0x7f1f99f74400, value=...) at WebCore/dom/Document.cpp:3016
#10 0x00007f1fa633610d in WebCore::setJSDocumentCookie (exec=<value optimized out>, thisObject=<value optimized out>, value=<value optimized out>) at DerivedSources/JSDocument.cpp:1070
#11 0x00007f1fa633cc79 in lookupPut<WebCore::JSDocument> (this=0x7f1f95cd0240, exec=0x7f1f9674d2b8, propertyName=..., value=..., slot=...) at ./JavaScriptCore/runtime/Lookup.h:303
#12 lookupPut<WebCore::JSDocument, WebCore::JSNode> (this=0x7f1f95cd0240, exec=0x7f1f9674d2b8, propertyName=..., value=..., slot=...) at ./JavaScriptCore/runtime/Lookup.h:317
#13 WebCore::JSDocument::put (this=0x7f1f95cd0240, exec=0x7f1f9674d2b8, propertyName=..., value=..., slot=...) at DerivedSources/JSDocument.cpp:1028
#14 0x00007f1fa63c56ca in lookupPut<WebCore::JSHTMLDocument, WebCore::JSDocument> (this=0x7f1f95cd0240, exec=0x7f1f9674d2b8, propertyName=..., value=<value optimized out>, slot=...) at ./JavaScriptCore/runtime/Lookup.h:318
#15 WebCore::JSHTMLDocument::put (this=0x7f1f95cd0240, exec=0x7f1f9674d2b8, propertyName=..., value=<value optimized out>, slot=...) at DerivedSources/JSHTMLDocument.cpp:315
#16 0x00007f1fa5b95f5f in JSC::JSValue::put (this=0x7fff5281ae20, flag=<value optimized out>, registerFile=<value optimized out>, callFrame=0x7f1f9674d2b8, exception=<value optimized out>) at ./JavaScriptCore/runtime/JSObject.h:656
#17 JSC::Interpreter::privateExecute (this=0x7fff5281ae20, flag=<value optimized out>, registerFile=<value optimized out>, callFrame=0x7f1f9674d2b8, exception=<value optimized out>) at JavaScriptCore/interpreter/Interpreter.cpp:2294
#18 0x00007f1fa5ba0940 in JSC::Interpreter::execute (this=0x7f1f99f98680, functionExecutable=<value optimized out>, callFrame=0x7f1f9a002748, function=0x7f1f95cd1400, thisObj=<value optimized out>, args=<value optimized out>, scopeChain=0x7f1f95c86cf0, exc#19 0x00007f1fa5c2b6a7 in JSC::JSFunction::call (this=0x7f1f95cd1400, exec=0x7f1f9a002748, thisValue=..., args=...) at JavaScriptCore/runtime/JSFunction.cpp:120
#20 0x00007f1fa5c0ea80 in JSC::call (exec=0x2, functionObject=..., callType=<value optimized out>, callData=..., thisValue=..., args=...) at JavaScriptCore/runtime/CallData.cpp:39
#21 0x00007f1fa5caae29 in WebCore::callInWorld (exec=0x7f1f9a002748, function=..., callType=JSC::CallTypeJS, callData=..., thisValue=<value optimized out>, args=<value optimized out>, isolatedWorld=0x7f1f99fa4f80) at WebCore/bindings/js/JSDOMBinding.cpp:83#22 0x00007f1fa5cc2794 in WebCore::JSEventListener::handleEvent (this=0x7f1f95c192a8, scriptExecutionContext=0x7f1f99f74458, event=<value optimized out>) at WebCore/bindings/js/JSEventListener.cpp:118
#23 0x00007f1fa5db8a37 in WebCore::EventTarget::fireEventListeners (this=0x7f1f99f74400, event=0x7f1f95c24120) at WebCore/dom/EventTarget.cpp:297
#24 0x00007f1fa5dc7375 in WebCore::Node::dispatchGenericEvent (this=0x7f1f99f74400, prpEvent=<value optimized out>) at WebCore/dom/Node.cpp:2523
#25 0x00007f1fa5dc7901 in WebCore::Node::dispatchEvent (this=0x7f1f99f74400, prpEvent=<value optimized out>) at WebCore/dom/Node.cpp:2446
#26 0x00007f1fa5d96414 in WebCore::Document::finishedParsing (this=0x7f1f99f74400) at WebCore/dom/Document.cpp:4036
#27 0x00007f1fa5ed5dec in WebCore::HTMLTokenizer::end (this=0x7f1f95bfb800) at WebCore/html/HTMLTokenizer.cpp:1863
#28 0x00007f1fa5edeeb9 in WebCore::HTMLTokenizer::finish (this=0x7f1f95bfb800) at WebCore/html/HTMLTokenizer.cpp:1903
#29 0x00007f1fa5f39447 in WebCore::FrameLoader::endIfNotLoadingMainResource (this=0x7f1f99f4f850) at WebCore/loader/FrameLoader.cpp:949
#30 0x00007f1fa5f35bd8 in WebCore::FrameLoader::finishedLoading (this=0x7f1f99f4f850) at WebCore/loader/FrameLoader.cpp:2699
#31 0x00007f1fa5f4a61f in WebCore::MainResourceLoader::didFinishLoading (this=0x7f1f99f98b00) at WebCore/loader/MainResourceLoader.cpp:393
#32 0x00007f1fa5f4d5e2 in WebCore::MainResourceLoader::continueAfterContentPolicy (this=0x7f1f99f98b00, contentPolicy=2784274064, r=...) at WebCore/loader/MainResourceLoader.cpp:264
#33 0x00007f1fa5f4d876 in WebCore::MainResourceLoader::continueAfterContentPolicy (this=0x7f1f99f98b00, policy=WebCore::PolicyUse) at WebCore/loader/MainResourceLoader.cpp:278
#34 0x00007f1fa5f4e1dd in WebCore::MainResourceLoader::callContinueAfterContentPolicy (this=0x7f1f99f98b00, r=...) at WebCore/loader/MainResourceLoader.cpp:270
#35 WebCore::MainResourceLoader::didReceiveResponse (this=0x7f1f99f98b00, r=...) at WebCore/loader/MainResourceLoader.cpp:336
#36 0x00007f1fa5f4b2b3 in WebCore::MainResourceLoader::handleDataLoadNow (this=0x7f1f99f98b00) at WebCore/loader/MainResourceLoader.cpp:438
#37 0x00007f1fa5fe23f6 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x7f1f99f43900) at WebCore/platform/ThreadTimers.cpp:112
#38 0x00007f1fa62ae492 in timeout_cb () at WebCore/platform/gtk/SharedTimerGtk.cpp:48
#39 0x00007f1fa2f8d12a in g_main_dispatch (context=0x2032940) at /tmp/buildd/glib2.0-2.22.2/glib/gmain.c:1960
#40 IA__g_main_context_dispatch (context=0x2032940) at /tmp/buildd/glib2.0-2.22.2/glib/gmain.c:2513
#41 0x00007f1fa2f90988 in g_main_context_iterate (context=0x2032940, block=1, dispatch=1, self=<value optimized out>) at /tmp/buildd/glib2.0-2.22.2/glib/gmain.c:2591
#42 0x00007f1fa2f90e5d in IA__g_main_loop_run (loop=0x20f3a70) at /tmp/buildd/glib2.0-2.22.2/glib/gmain.c:2799
#43 0x00007f1fa53b7ca7 in IA__gtk_main () at /tmp/buildd/gtk+2.0-2.18.3/gtk/gtkmain.c:1218
#44 0x0000000000400f85 in main (argc=1, argv=0x7fff5281c3f8) at test-webkit-crash.c:68
Comment 1 Gustavo Noronha (kov) 2009-11-20 05:02:27 PST
This is a bug in libsoup. Bug report, and patch here: https://bugzilla.gnome.org/show_bug.cgi?id=602498

We may want to add a work-around nevertheless?
Comment 2 Gustavo Noronha (kov) 2009-11-20 05:17:27 PST
Created attachment 43573 [details]
work around

I submitted a patch to soup, but perhaps we should add this work-around to webkit as well, so that people who don't upgrade soup don't get crashes.
Comment 3 Eric Seidel 2009-11-21 07:11:34 PST
Comment on attachment 43573 [details]
work around

Should we wrap this in a version check for lib soup?

Also, what's a cookie with no domain look like?  How does one ever set one?

Would a javascript: url which manipulates document.cookies work as a unit test?

Could you take an iframe and have it load up a javascript:document.cookies = "foo" url (or whatever the proper cookie-setting code would be?
Comment 4 Adrian Bunk 2009-11-21 14:58:12 PST
(In reply to comment #3)
> (From update of attachment 43573 [details])
> Should we wrap this in a version check for lib soup?

Before you are doing too complicated things here you could also consider not changing WebKit's code but bumping WebKit's libsoup dependency instead.

WebKit already requires as a minimum a development verion of libsoup shortly before 2.28, and assuming a libsoup 2.28.2 with this fix included comes out soon that wouldn't be a big version bump.

In Liferea (the application much affected by this bug) I plan to increase the libsoup dependency in trunk (that is for unrelated reasons already at 2.28) instead of bumping the WebKit dependency from currently 1.1.11.
Comment 5 Oliver Hunt 2009-11-22 21:45:16 PST
Comment on attachment 43573 [details]
work around

Comment 6 Gustavo Noronha (kov) 2009-12-08 06:27:45 PST
We decided to not apply this work-around, and depend on a newer soup instead. Thanks all.