Bug 109715
Summary: | [GTK][WK2] Crash when printing | ||
---|---|---|---|
Product: | WebKit | Reporter: | Claudio Saavedra <csaavedra> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | UNCONFIRMED | ||
Severity: | Normal | CC: | bugs-noreply, cgarcia, svillar |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Claudio Saavedra
(gdb) back
#0 0x00007ffff608c52a in drawPagesForPrintingCompleted(OpaqueWKError const*, OpaqueWKError const*, void*) ()
from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.0
#1 0x00007ffff6108e07 in void WebKit::invalidateCallbackMap<WTF::RefPtr<WebKit::GenericCallback<OpaqueWKError const*, WebKit::WebError*> > >(WTF::HashMap<unsigned long, WTF::RefPtr<WebKit::GenericCallback<OpaqueWKError const*, WebKit::WebError*> >, WTF::IntHash<unsigned long>, WTF::HashTraits<unsigned long>, WTF::HashTraits<WTF::RefPtr<WebKit::GenericCallback<OpaqueWKError const*, WebKit::WebError*> > > >&) () from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.0
#2 0x00007ffff60f810a in WebKit::WebPageProxy::processDidCrash() () from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.0
#3 0x00007ffff6113432 in WebKit::WebProcessProxy::didClose(CoreIPC::Connection*) () from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.0
#4 0x00007ffff707b5eb in WebCore::RunLoop::performWork() () from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.0
#5 0x00007ffff7545919 in WebCore::RunLoop::queueWork(WebCore::RunLoop*) () from /opt/gnome-3.0/lib64/libwebkit2gtk-3.0.so.0
#6 0x00007ffff0f099a7 in g_idle_dispatch (source=0x7fff80050930,
callback=0x7ffff7545910 <WebCore::RunLoop::queueWork(WebCore::RunLoop*)>, user_data=0x7fffe2f10c98) at gmain.c:5205
#7 0x00007ffff0f07225 in g_main_dispatch (context=0x71b640) at gmain.c:3054
#8 0x00007ffff0f07f8a in g_main_context_dispatch (context=0x71b640) at gmain.c:3630
#9 0x00007ffff0f0817a in g_main_context_iterate (context=0x71b640, block=1, dispatch=1, self=0x75b120) at gmain.c:3701
#10 0x00007ffff0f0823e in g_main_context_iteration (context=0x71b640, may_block=1) at gmain.c:3762
#11 0x00007ffff1733929 in g_application_run (application=0x8cc000, argc=1, argv=0x7fffffffd678) at gapplication.c:1620
#12 0x000000000042f9ed in main (argc=1, argv=0x7fffffffd678) at ephy-main.c:474
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Sergio Villar Senin
hmm have just tried to print using epy with WK2 and everything went fine (I'm using r143188). Are you able to reproduce it consistently with any particular webpage?
Claudio Saavedra
No, not really. However from the stacktrace this looks related to the webprocess crashing and I remember there were other bugs in which the ui process would crash when the webprocess crashed (see bug 109305). My guess is that one needs to kill the WebProcess while the printing is happening and this might happen as a result.
From a quick look at the code, WebKit::WebPageProxy::processDidCrash() marks the proxy as invalid before calling invalidateCallbackMap() on the printing callbacks. Then this ends up calling drawPagesForPrintingCompleted(). is there any way to test what happens when the web process crashes? That would be handy.
Sergio Villar Senin
(In reply to comment #2)
> No, not really. However from the stacktrace this looks related to the webprocess crashing and I remember there were other bugs in which the ui process would crash when the webprocess crashed (see bug 109305). My guess is that one needs to kill the WebProcess while the printing is happening and this might happen as a result.
>
> From a quick look at the code, WebKit::WebPageProxy::processDidCrash() marks the proxy as invalid before calling invalidateCallbackMap() on the printing callbacks. Then this ends up calling drawPagesForPrintingCompleted(). is there any way to test what happens when the web process crashes? That would be handy.
gdb -p `pidof WebKitWebProcess` should attach a gdb to the WebProcess
Claudio Saavedra
I know :) I mean whether we can have tests that purposely crash the webprocess so that we can test how does the UI process respond to the other end crashing.