Bug 53057 - [GTK] Two tests crash after r76555
Summary: [GTK] Two tests crash after r76555
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P3 Normal
Assignee: Nobody
Keywords: Gtk
Depends on:
Reported: 2011-01-24 18:01 PST by Martin Robinson
Modified: 2011-02-01 17:32 PST (History)
2 users (show)

See Also:

Patch (3.61 KB, patch)
2011-01-25 12:39 PST, Martin Robinson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Robinson 2011-01-24 18:01:28 PST
Two tests crash after r76555: 
http/tests/xmlhttprequest/simple-cross-origin-denied-events-post.html and http/tests/xmlhttprequest/simple-cross-origin-denied-events-sync.html. Here is the stack trace:

#0  0x00007f02754aff01 in WebCore::sendRequestCallback (source=0x1872540, res=0x1871520, userData=0x0) at ../../Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:513
513	            client->didFail(handle.get(), resourceError);

Thread 1 (Thread 8568):
#0  0x00007f02754aff01 in WebCore::sendRequestCallback (source=0x1872540, res=0x1871520, userData=0x0) at ../../Source/WebCore/platform/network/soup/ResourceHandleSoup.cpp:513
#1  0x00007f02754be8bd in sent_async (source=0x11296e0, result=0x18715e0, user_data=0x1871520) at ../../Source/WebCore/platform/network/soup/cache/soup-request-http.c:119
#2  0x00007f02754bc592 in wrapper_callback (source_object=0x11296e0, res=0x18715e0, user_data=0x1871520) at ../../Source/WebCore/platform/network/soup/cache/soup-http-input-stream.c:540
#3  0x00007f02754bc7a2 in send_async_finished (stream=0x11296e0) at ../../Source/WebCore/platform/network/soup/cache/soup-http-input-stream.c:600
#4  0x00007f02754bbd53 in webkit_soup_http_input_stream_finished (msg=0x17b4b20, stream=0x11296e0) at ../../Source/WebCore/platform/network/soup/cache/soup-http-input-stream.c:311
#5  0x00007f0277c87d1e in g_closure_invoke (closure=0x1892dd0, return_value=0x0, n_param_values=1, param_values=0x11dbc60, invocation_hint=0x7fffecbfe690) at /home/kov/debian/tmp/glib2.0-
#6  0x00007f0277ca0d99 in signal_emit_unlocked_R (node=0x17b21f0, detail=<value optimized out>, instance=<value optimized out>, emission_return=<value optimized out>, instance_and_params=<value optimized out>) at /home/kov/debian/tmp/glib2.0-
#7  0x00007f0277ca2516 in g_signal_emit_valist (instance=0x17b4b20, signal_id=<value optimized out>, detail=0, var_args=0x7fffecbfe880) at /home/kov/debian/tmp/glib2.0-
#8  0x00007f0277ca2d43 in g_signal_emit (instance=0x188bfe8, signal_id=6, detail=1) at /home/kov/debian/tmp/glib2.0-
#9  0x00007f0277e3fb23 in process_queue_item (item=0x11b7ea0, should_prune=0x7fffecbfe9bc, loop=1) at soup-session-async.c:376
#10 0x00007f0277e3fe81 in run_queue (sa=<value optimized out>) at soup-session-async.c:418
#11 0x00007f0277e3ff33 in idle_run_queue (sa=0x7f0264001030) at soup-session-async.c:443
#12 0x00007f02734ed0b2 in g_main_dispatch (context=0x1127ee0) at /home/kov/debian/tmp/glib2.0-
#13 g_main_context_dispatch (context=0x1127ee0) at /home/kov/debian/tmp/glib2.0-
#14 0x00007f02734f1778 in g_main_context_iterate (context=0x1127ee0, block=<value optimized out>, dispatch=<value optimized out>, self=<value optimized out>) at /home/kov/debian/tmp/glib2.0-
#15 0x00007f02734f1c85 in g_main_loop_run (loop=0x17b4740) at /home/kov/debian/tmp/glib2.0-
#16 0x00007f0274649657 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x000000000041cac5 in runTest (testPathOrURL=...) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:655
#18 0x000000000041c19a in runTestingServerLoop () at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:469
#19 0x000000000041e09b in main (argc=2, argv=0x7fffecbff5e8) at ../../Tools/DumpRenderTree/gtk/DumpRenderTree.cpp:1096

I will try to resolve this first thing tomorrow.
Comment 1 Martin Robinson 2011-01-25 11:45:04 PST
The issue here is that we are calling handle->start(...) unconditionally even if there is a scheduled failure. I believe we can remedy this problem by calling ::create instead of creating the handle manually. Should have a patch soon.
Comment 2 Martin Robinson 2011-01-25 12:39:17 PST
Created attachment 80104 [details]
Comment 3 Gustavo Noronha (kov) 2011-02-01 14:29:58 PST
Comment on attachment 80104 [details]

Tests are no longer timing out I assume? =)
Comment 4 Martin Robinson 2011-02-01 14:33:35 PST
(In reply to comment #3)
> (From update of attachment 80104 [details])
> Tests are no longer timing out I assume? =)

Thanks for the review! Tests still do not timeout because

1. ResourceHandle::create does not call handle->start if there is a scheduled failure.
2. The Soup caller does not start the internal event loop if there is a scheduled failure.
Comment 5 Martin Robinson 2011-02-01 17:31:51 PST
Committed r77343: <http://trac.webkit.org/changeset/77343>