27.09.2017, 19:30, "Leo Ufimtsev" <leoni...@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@entry=true, run_dtors=run_dtors@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@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-help -- Regards, Konstantin _______________________________________________ webkit-help mailing list webkit-help@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-help
