[webkit-help] Webkitgtk crashes on disposal as of ~2.18?

Konstantin Tokarev annulen at yandex.ru
Wed Sep 27 09:36:55 PDT 2017



27.09.2017, 19:30, "Leo Ufimtsev" <leonidas at redhat.com>:
> Hello WebkitGtk developers,
>
> I"m having a hard time figuring out why webkit crashe as of 2.18 with us, I was wondering if the below stack trace looks familiar to anyone?
>
> Context:
> - We use WebkiGtk for Eclipse's/SWT's Browser functionality on Linux. (Java native Interface to Webkitgtk)
> - We have a custom container for widget layout.
>
> In 2.16, all was fine. As of 2.18, when we exit Eclipse, Webkit now crashes with the following backtrace:
>
> (Stack trace was shortened/reduced for clarity)

Looks like you are using WebKit build in debug mode with enabled asserts. Such build is less efficient and you can get a lot of crashes depending on browsed content, so it's better to use build with disabled asserts unless you are developing WebKit itself.

> (gdb) bt
> #0  WTFCrash() () at Source/WTF/wtf/Assertions.cpp:278
> #1  WebKit::CallbackMap::invalidate(WebKit::CallbackBase::Error)
>           (error=WebKit::CallbackBase::Error::OwnerWasInvalidated) /WebKit/UIProcess/GenericCallback.h:225
> #2  WebKit::WebCookieManagerProxy::processPoolDestroyed() /WebKit/UIProcess/WebCookieManagerProxy.cpp:76
> #3  WebKit::WebProcessPool::~WebProcessPool()  __in_chrg=.. /Source/WebKit/UIProcess/WebProcessPool.cpp:298
> #4  WebKit::WebProcessPool::~WebProcessPool()  WebKit/UIProcess/WebProcessPool.cpp:317
> #5  WTF::ThreadSafeRefCounted<API::Object>::deref() const .. WTF/wtf/ThreadSafeRefCounted.h:71
> #6  WTF::derefIfNotNull<WebKit::WebProcessPool>(WebKit::WebProcessPool*)(ptr=../WTF/wtf/RefPtr.h:45
> #7  WTF::RefPtr<WebKit::WebProcessPool>::~RefPtr() __in_chrg=.. /WTF/wtf/RefPtr.h:69
> #8  _WebKitWebContextPrivate::~_WebKitWebContextPrivate()  __in_chrg=. /WebKit/UIProcess/API/glib/WebKitWebContext.cpp:163
> #9  webkit_web_context_finalize(GObject*) (object=... /WebKit/UIProcess/API/glib/WebKitWebContext.cpp:245
> #10 g_object_unref (_object=0x7fde296e7110) at gobject.c:3185
> #11 __run_exit_handlers (status=0, listp=0x7.... <__exit_funcs>, run_list_atexit=run_list_atexit at entry=true, run_dtors=run_dtors at entry=true) at exit.c:83
> #12 __GI_exit (status=<optimized out>) at exit.c:105
> #13 __libc_start_main (main=0x151b63e670 <main>, argc=5, argv=0x7ffc1db781f8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc1db781e8)
>     at ../csu/libc-start.c:329
> #14in _start ()
> ...
> 1    /lib64/libjavascriptcoregtk-4.0.so.18 WTFCrash
> 2    /lib64/libwebkit2gtk-4.0.so.37
> ..6    /lib64/libgobject-2.0.so.0(g_object_unref..)
> ..9    /lib64/libc.so.6(__libc_start_main..)
> ..10   /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-7.b12.fc26.x86_64/bin/java
>
> I noticed that if I do an g_object_ref(webview) somewhere near disposal, then the crash doesn't occur. Also if we don't gtk_container_add(..) webview, then the crash doesn't occur either.
>
> Does the above ring a bell with anyone?
>
> Was there a mechanism added to webkit/webkitgtk to somehow auto-cleanup somewhere that didn't exist before?
>
> Thank you.
>
> --
> Leo Ufimtsev, Software Engineer, Red Hat
> ,
>
> _______________________________________________
> webkit-help mailing list
> webkit-help at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-help


-- 
Regards,
Konstantin


More information about the webkit-help mailing list