Bugzilla – Full Text Bug Listing
| Summary: | WebviewExitFullScreen null pointer dereference in webview causes JVM Crash | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Ragnar Rova <ragnar.rova> | ||||||
| Component: | SWT | Assignee: | Grant Gayed <grant_gayed> | ||||||
| Status: | RESOLVED WORKSFORME | QA Contact: | |||||||
| Severity: | major | ||||||||
| Priority: | P3 | CC: | arunkumar.thondapu, eclipse.felipe | ||||||
| Version: | 3.7 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Linux-GTK | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Ragnar Rova
Created attachment 203353 [details] JRockit JVM crash dump I think the c++ function called looks like this: http://www.opensource.apple.com/source/WebKit/WebKit-7534.48.3/gtk/webkit/webkitwebview.cpp: void webViewExitFullscreen(WebKitWebView* webView) { #if ENABLE(VIDEO) WebKitWebViewPrivate* priv = webView->priv; if (priv->fullscreenVideoController) priv->fullscreenVideoController->exitFullscreen(); #endif } So there are three possible null pointers in that function. Core dump stack backtrace from gdb (I can send coredump privately if needed): Core was generated by `/usr/lib/jvm/jrockit-jdk1.6.0_26-R28.1.4-4.0.1/bin/java -Xms384m -Xmx384m -XgcP'. Program terminated with signal 6, Aborted. #0 0x00007f8c087c2450 in ?? () from /usr/lib/libwebkitgtk-1.0.so.0 (gdb) bt #0 0x00007f8c087c2450 in ?? () from /usr/lib/libwebkitgtk-1.0.so.0 #1 0x00007f8c087a4398 in ?? () from /usr/lib/libwebkitgtk-1.0.so.0 #2 0x00007f8c087a4419 in ?? () from /usr/lib/libwebkitgtk-1.0.so.0 #3 0x00007f8c2e9aa34b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x00007f8c2e9a8b6d in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x00007f8c2e9a9368 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x00007f8c2e9a9539 in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #7 0x00007f8c22e48fa4 in Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration () from /home/rr/eclipse/configuration/org.eclipse.osgi/bundles/154/1/.cp/libswt-pi-gtk-3735.so #8 0x00007f8c307a9fc0 in ?? () #9 0x00000000e93d3cd8 in ?? () #10 0x000000000320fbc0 in ?? () #11 0x00007f8c307a9fbb in ?? () #12 0x0000000002674068 in ?? () #13 0x00007f8c725de3f0 in ?? () #14 0x00000000ef1718a8 in ?? () #15 0x00000000017bdd40 in ?? () #16 0x0000000000000000 in ?? () Here the core dump backtrace with debugging symbols enabled.
(gdb) bt
#0 0x00007f8c087c2450 in WebKit::core (webView=0x70cd120) at ../Source/WebKit/gtk/webkit/webkitwebview.cpp:5168
#1 0x00007f8c087a4398 in WebKit::GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars (this=0x7f8c005ffcc0)
at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:61
#2 0x00007f8c087a4419 in WebKit::updateAdjustmentCallback (watcher=<optimized out>)
at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:72
#3 0x00007f8c2e9aa34b in g_timeout_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:3907
#4 0x00007f8c2e9a8b6d in g_main_dispatch (context=0x26852b0) at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:2441
#5 g_main_context_dispatch (context=0x26852b0) at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:3011
#6 0x00007f8c2e9a9368 in g_main_context_iterate (context=0x26852b0, block=<optimized out>, dispatch=1, self=<optimized out>)
at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:3089
#7 0x00007f8c2e9a9539 in g_main_context_iteration (context=0x26852b0, may_block=0) at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:3152
#8 0x00007f8c22e48fa4 in Java_org_eclipse_swt_internal_gtk_OS__1g_1main_1context_1iteration ()
from /home/rr/eclipse/configuration/org.eclipse.osgi/bundles/154/1/.cp/libswt-pi-gtk-3735.so
#0 0x00007f8c087c2450 in WebKit::core (webView=0x70cd120) at ../Source/WebKit/gtk/webkit/webkitwebview.cpp:5168
5168 return priv ? priv->corePage : 0;
(gdb) print *webView
$5 = {parent_instance = {widget = {object = {parent_instance = {g_type_instance = {g_class = 0x0}, ref_count = 0,
qdata = 0xaaaaaaaaaaaaaaaa}, flags = 2863311530}, private_flags = 43690, state = 170 '\252', saved_state = 170 '\252',
name = 0xaaaaaaaaaaaaaaaa <Address 0xaaaaaaaaaaaaaaaa out of bounds>, style = 0xaaaaaaaaaaaaaaaa, requisition = {width = -1431655766,
height = -1431655766}, allocation = {x = -1431655766, y = -1431655766, width = -1431655766, height = -1431655766},
window = 0xaaaaaaaaaaaaaaaa, parent = 0xaaaaaaaaaaaaaaaa}, focus_child = 0xaaaaaaaaaaaaaaaa, border_width = 43690, need_resize = 0,
resize_mode = 1, reallocate_redraws = 1, has_focus_chain = 0}, priv = 0xaaaaaaaaaaaaaaaa}
(gdb) up
#1 0x00007f8c087a4398 in WebKit::GtkAdjustmentWatcher::updateAdjustmentsFromScrollbars (this=0x7f8c005ffcc0)
at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:61
61 if (!core(m_webView) || !core(m_webView)->mainFrame())
(gdb) print *this
$6 = {m_webView = 0x70cd120, m_horizontalAdjustment = {m_ptr = 0x7f8c2989b280}, m_verticalAdjustment = {m_ptr = 0x7f8c29984d40},
m_handlingGtkAdjustmentChange = false, m_updateAdjustmentCallbackId = 0}
(gdb) up
#2 0x00007f8c087a4419 in WebKit::updateAdjustmentCallback (watcher=<optimized out>)
at ../Source/WebKit/gtk/WebCoreSupport/GtkAdjustmentWatcher.cpp:72
72 watcher->updateAdjustmentsFromScrollbars();
(gdb) up
#3 0x00007f8c2e9aa34b in g_timeout_dispatch (source=<optimized out>, callback=<optimized out>, user_data=<optimized out>)
at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:3907
3907 /build/buildd/glib2.0-2.29.90/./glib/gmain.c: No such file or directory.
in /build/buildd/glib2.0-2.29.90/./glib/gmain.c
(gdb) up
#4 0x00007f8c2e9a8b6d in g_main_dispatch (context=0x26852b0) at /build/buildd/glib2.0-2.29.90/./glib/gmain.c:2441
2441 in /build/buildd/glib2.0-2.29.90/./glib/gmain.c
(gdb) print *context
$7 = {mutex = {runtime_mutex = 0x0, static_mutex = {pad = '\000' <repeats 39 times>, dummy_double = 0, dummy_pointer = 0x0,
dummy_long = 0}}, cond = 0x0, owner = 0x262be20, owner_count = 1, waiters = 0x0, ref_count = 1, pending_dispatches = 0x262c5a0,
timeout = 0, next_id = 117440, source_list = 0x2685190, in_check_or_prepare = 0, poll_records = 0x262c600, poll_records_tail = 0x8404300,
n_poll_records = 3, cached_poll_array = 0x7f8c285b83a0, cached_poll_array_size = 3, wakeup = 0x262a960, wake_up_rec = {fd = 14,
events = 1, revents = 0}, poll_waiting = 0, poll_changed = 0, poll_func = 0x7f8c2e9b7620 <g_poll>, time = 14178000809,
time_is_fresh = 1, real_time = 0, real_time_is_fresh = 0}
(gdb) up
Please note that JVM says crash occurred in webViewExitFullscreen+48() whereas gdb thinks it is in WebKit.core(...) JVM call trace is more right I guess, must be a source code / library mismatch when I created the stack backtrace... Without a reproducible case I don't think we can do much, sorry. Note that jrockit is not VM that we officially support. Adjusting Importance field since it happens primarily on an unsupported JRE. I notice in the comment 1 dump that libraries are loaded for both webkitgtk and xulrunner, so presumably webkitgtk is being used for default-style Browsers and xulrunner is being explicitly requested by an app you're using on top of eclipse. The mixing of these browser types has proven to be problematic sometimes, so a means of avoiding it was introduced in the eclipse 3.7.1 stream, see bug 349837. To see if this is indeed the issue, please get the 3.7.1 release at http://download.eclipse.org/eclipse/downloads/drops/M20110909-1335/index.php and add the following to the end of its eclipse.ini file: -Dorg.eclipse.swt.browser.DefaultType=mozilla Created attachment 203957 [details]
JDK 1.7 crash dump (not jrockit)
JDK 1.7 crashdump with hotspot jvm, shows that this is not jrockit-specific. I will try the eclipse build above and Dorg.eclipse.swt.browser.DefaultType=mozilla
-Dorg.eclipse.swt.browser.DefaultType=mozilla on 3.7.1 did help. You can resolve this bug Consider making mozilla the default swt browser? It is still not clear if mixing webkit and xulrunner is the cause, or if it just a bug when using webkit in general. But switching to mozilla did help. It's true that setting the the switch does not prove that it's not a webkit bug, but this pattern of crashes where both webkit and xulrunner are loaded has been recurring. I was previously able to reproduce a case of this and proved that a library conflict was the cause by varying the order that dependent libraries were loaded. Mozilla was the default Browser renderer on linux for many years, but going back to that is definitely not desirable or possible, especially given their new rapid release cycle and official "no frozen interfaces" policy. It's now the responsibility of apps that create SWT.MOZILLA-style Browsers to set this switch. Closing report. |