| Summary: | [GTK] UI process crash in WebCore::PasteboardHelper::fillSelectionData | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Catanzaro <mcatanzaro> | ||||
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||
| Status: | NEW --- | ||||||
| Severity: | Normal | CC: | bugs-noreply, mcatanzaro, tpopela, tsaunier | ||||
| Priority: | P2 | ||||||
| Version: | WebKit Nightly Build | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| See Also: |
https://bugzilla.redhat.com/show_bug.cgi?id=1423979 https://bugs.webkit.org/show_bug.cgi?id=174161 https://bugzilla.redhat.com/show_bug.cgi?id=1524598 https://bugzilla.redhat.com/show_bug.cgi?id=1541220 https://bugzilla.redhat.com/show_bug.cgi?id=1570323 https://bugzilla.redhat.com/show_bug.cgi?id=1615699 |
||||||
| Attachments: |
|
||||||
(In reply to Michael Catanzaro from comment #0) > I hit this after 20 minutes of editing the CSS grid layout blog post and > lost all my work. :( And today I just lost a long email to this crash in Geary. :/ I'll attach a better backtrace. Created attachment 328990 [details]
Backtrace
Looks like a duplicate of bug #174161, but that is supposed to be fixed in 2.18, and I just hit this crash with 2.18.3. (In reply to Michael Catanzaro from comment #3) > Looks like a duplicate of bug #174161, but that is supposed to be fixed in > 2.18, and I just hit this crash with 2.18.3. There are two overloads of PasteboardHelper::fillSelectionData. Bug #174161 fixed PasteboardHelper::fillSelectionData(GtkSelectionData*, unsigned, SelectionData&), but PasteboardHelper::fillSelectionData(const SelectionData&, unsigned, GtkSelectionData*) is still broken. It's not as simple as I'd hoped:
CString String::utf8(ConversionMode mode) const
{
if (!m_impl) <------------------ crash is right here
return CString("", 0);
return m_impl->utf8(mode);
}
this and m_impl are both 0x8, which is not 0. I guess m_impl has somehow become corrupted. Without a reproducer, this will be hard to debug.
info registers
rax 0x0 0
rbx 0x7ffe687b1490 140730651317392
rcx 0x7ffe687b20c0 140730651320512
rdx 0x0 0
rsi 0x8 8 <--- There it is, not sure if that's significant
rdi 0x7ffe687b1490 140730651317392
rbp 0x558ff93b9360 0x558ff93b9360
rsp 0x7ffe687b1420 0x7ffe687b1420
r8 0x558ffa3aa5b0 94076866831792
r9 0x4 4
r10 0x558ff92f5f28 94076849315624
r11 0x558ffa3aa5b0 94076866831792
r12 0x0 0
r13 0x7ffe687b1730 140730651318064
r14 0x7ffe687b16b0 140730651317936
r15 0x7fd7ed0e7c70 140565371845744
rip 0x7fd7ece81d38 0x7fd7ece81d38 <WTF::String::utf8(WTF::ConversionMode) const+8>
eflags 0x10202 [ IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
Oh, the problem is that selection, the first parameter, is null. That's bad, because it's a reference parameter, so it's supposed to be guaranteed to be nonnull here. I think, if this were a debug build, we would be hitting this assert:
// This can happen when attempting to call finish drag from webkitWebViewBaseDragDataGet()
// for a obsolete DnD operation that got previously cancelled in startDrag().
if (m_dragContext.get() != context)
return;
ASSERT(m_draggingSelectionData);
PasteboardHelper::singleton().fillSelectionData(*m_draggingSelectionData, info, selectionData);
in DragAndDropHandler::fillDragData. That is, m_dragContext.get() == context, yet the drag methods are called out of order for whatever reason. I guess either DragAndDropHandler::fillDragData is being called before DragAndDropHandler::startDrag, or it's being called after DragAndDropHandler::finishDrag. That is weird.
(In reply to Michael Catanzaro from comment #7) > I guess either DragAndDropHandler::fillDragData is being called before > DragAndDropHandler::startDrag, or it's being called after > DragAndDropHandler::finishDrag. That is weird. But I don't think that is possible.... We have 84 reports of this one. I think I see this one a lot more often than that, though. This seems to be a regular UI process crasher. It happens sometimes when dragging selected text. I got a crash with a similare trace today, I will paste the trace here in case it helps, I can also open a new bug if you think it is more appropriate:
#0 0x00007fa7ec432512 in WebCore::PasteboardHelper::fillSelectionData(WebCore::SelectionData const&, unsigned int, _GtkSelectionData*) () at /run/build-runtime/WebKitGTK /DerivedSources/ForwardingHeaders/wtf/HashTable.h:379
#1 0x00007fa7ec432512 in WebCore::PasteboardHelper::fillSelectionData(WebCore::SelectionData const&, unsigned int, _GtkSelectionData*) () at /run/build-runtime/WebKitGTK /DerivedSources/ForwardingHeaders/wtf/HashMap.h:260
#2 0x00007fa7ec432512 in WebCore::PasteboardHelper::fillSelectionData(WebCore::SelectionData const&, unsigned int, _GtkSelectionData*) () at /run/build-runtime/WebKitGTK /Source/WebCore/platform/gtk/PasteboardHelper.cpp:197
#6 0x00007fa7ef6ccfcb in <emit signal 0x7fa7eeaa5a92 "drag-data-get" on instance 0x36a90c0 [EphyWebView]> (instance=0x36a90c0, detailed_signal=detailed_signal@entry=0x7fa7eeaa5a92 "drag-data-get") at gsignal.c:3487
#3 0x00007fa7ef6b1475 in g_closure_invoke (closure=closure@entry=0x1a07160, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7ffc87735d50, invocation_hint=invocation_hint@entry=0x7ffc87735cd0) at gclosure.c:804
#4 0x00007fa7ef6c406d in signal_emit_unlocked_R (node=node@entry=0x1a0bf40, detail=detail@entry=0, instance=instance@entry=0x36a90c0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffc87735d50) at gsignal.c:3673
#5 0x00007fa7ef6cc738 in g_signal_emit_valist (instance=instance@entry=0x36a90c0, signal_id=signal_id@entry=114, detail=detail@entry=0, var_args=var_args@entry=0x7ffc87735fa8) at gsignal.c:3391
#7 0x00007fa7eea7d8fd in gtk_drag_selection_get (widget=<optimized out>, selection_data=0x7ffc877366a0, sel_info=<optimized out>, time=165141967, data=0x62e6f60) at gtkdnd.c:2725
#11 0x00007fa7ef6ccfcb in <emit signal 0x7fa7eeb00167 "selection-get" on instance 0x19dfcb0 [GtkWindow]> (instance=instance@entry=0x19dfcb0, detailed_signal=detailed_signal@entry=0x7fa7eeb00167 "selection-get") at gsignal.c:3487
#8 0x00007fa7ef6b1475 in g_closure_invoke (closure=0x5f98fa0, return_value=return_value@entry=0x0, n_param_values=4, param_values=param_values@entry=0x7ffc877362d0, invocation_hint=invocation_hint@entry=0x7ffc87736250) at gclosure.c:804
#9 0x00007fa7ef6c3c72 in signal_emit_unlocked_R (node=node@entry=0x1a0a8d0, detail=detail@entry=0, instance=instance@entry=0x19dfcb0, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffc877362d0) at gsignal.c:3635
#10 0x00007fa7ef6cc738 in g_signal_emit_valist (instance=instance@entry=0x19dfcb0, signal_id=signal_id@entry=104, detail=detail@entry=0, var_args=var_args@entry=0x7ffc87736508) at gsignal.c:3391
#12 0x00007fa7ee992abb in gtk_selection_invoke_handler (widget=0x19dfcb0 [GtkWindow], data=0x7ffc877366a0, time=165141967) at gtkselection.c:3083
#13 0x00007fa7ee992d8f in gtk_selection_convert (widget=0x19df4d0 [GtkWindow], selection=0x46, target=0x55, time_=165141967) at gtkselection.c:1155
#14 0x00007fa7eaf11262 in WebKit::DragAndDropHandler::dragDataSelection(_GdkDragContext*, WebCore::IntPoint const&, unsigned int) () at /run/build-runtime/WebKitGTK /Source/WebKit/UIProcess/gtk/DragAndDropHandler.cpp:227
#15 0x00007fa7eaf1153f in WebKit::DragAndDropHandler::dragMotion(_GdkDragContext*, WebCore::IntPoint const&, unsigned int) () at /run/build-runtime/WebKitGTK /Source/WebKit/UIProcess/gtk/DragAndDropHandler.cpp:241
#16 0x00007fa7eaeefc60 in webkitWebViewBaseDragMotion() () at /run/build-runtime/WebKitGTK /Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:1214
#21 0x00007fa7ef6ccfcb in <emit signal 0x7fa7eead3460 "drag-motion" on instance 0x36a90c0 [EphyWebView]> (instance=instance@entry=0x36a90c0, detailed_signal=detailed_signal@entry=0x7fa7eead3460 "drag-motion") at gsignal.c:3487
#17 0x00007fa7ee904b17 in _gtk_marshal_BOOLEAN__OBJECT_INT_INT_UINT (closure=0x1a073c0, return_value=0x7ffc87736a10, n_param_values=<optimized out>, param_values=0x7ffc87736a70, invocation_hint=<optimized out>, marshal_data=<optimized out>) at gtkmarshalers.c:808
#18 0x00007fa7ef6b1475 in g_closure_invoke (closure=closure@entry=0x1a073c0, return_value=return_value@entry=0x7ffc87736a10, n_param_values=5, param_values=param_values@entry=0x7ffc87736a70, invocation_hint=invocation_hint@entry=0x7ffc877369f0) at gclosure.c:804
#19 0x00007fa7ef6c406d in signal_emit_unlocked_R (node=node@entry=0x1a0ab10, detail=detail@entry=0, instance=instance@entry=0x36a90c0, emission_return=emission_return@entry=0x7ffc87736bd0, instance_and_params=instance_and_params@entry=0x7ffc87736a70) at gsignal.c:3673
#20 0x00007fa7ef6cc1d7 in g_signal_emit_valist (instance=instance@entry=0x36a90c0, signal_id=signal_id@entry=112, detail=detail@entry=0, var_args=var_args@entry=0x7ffc87736cc8) at gsignal.c:3401
#22 0x00007fa7eea7ea98 in gtk_drag_dest_motion (widget=0x36a90c0 [EphyWebView], context=0x19c58e0 [GdkWaylandDragContext], x=64, y=191, time=165141967) at gtkdnd.c:1572
#23 0x00007fa7eea7f150 in _gtk_drag_dest_handle_event (callback=0x7fa7eea7e960 <gtk_drag_dest_motion>, time=165141967, y=<optimized out>, x=<optimized out>, info=0x7fa72c2eec10, context=0x19c58e0 [GdkWaylandDragContext], widget=0x36a90c0 [EphyWebView]) at gtkdnd.c:1270
#24 0x00007fa7eea7f150 in _gtk_drag_dest_handle_event (toplevel=toplevel@entry=0x2054ad0 [EphyWindow], event=event@entry=0x3e40500) at gtkdnd.c:1091
#25 0x00007fa7ee902a7a in gtk_main_do_event (event=0x3e40500) at gtkmain.c:1933
#26 0x00007fa7ed747dd5 in _gdk_event_emit (event=event@entry=0x3e40500) at gdkevents.c:73
#27 0x00007fa7ed79d212 in gdk_event_source_dispatch (base=<optimized out>, callback=<optimized out>, data=<optimized out>) at gdkeventsource.c:124
#28 0x00007fa7ef3d6ab7 in g_main_context_dispatch (context=0x19a4310) at gmain.c:3177
#29 0x00007fa7ef3d6ab7 in g_main_context_dispatch (context=context@entry=0x19a4310) at gmain.c:3830
#30 0x00007fa7ef3d6d28 in g_main_context_iterate (context=context@entry=0x19a4310, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3903
#31 0x00007fa7ef3d6ddc in g_main_context_iteration (context=context@entry=0x19a4310, may_block=may_block@entry=1) at gmain.c:3964
#32 0x00007fa7ef08e7ad in g_application_run (application=0x1a32170 [EphyShell], argc=1, argv=0x7ffc87737238) at gapplication.c:2470
#33 0x0000000000402709 in ()
#34 0x0000003ecfe20291 in __libc_start_main (main=0x402230, argc=1, argv=0x7ffc87737238, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc87737228) at /usr/src/debug/glibc/2.24-r0/git/csu/libc-start.c:289
#35 0x0000000000402a6a in ()
(flatpak-coredumpctl made it possible to retrieve that one very easily \o/)
|
I hit this after 20 minutes of editing the CSS grid layout blog post and lost all my work. :( The backtrace is not very great due to a gdb bug, but it looks like we got the first frames: Thread 1 (Thread 0x7f2faec05fc0 (LWP 3337)): #0 0x00007f2faafc8c38 in WTF::RefPtr<WTF::StringImpl>::operator!() const (this=<optimized out>) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/RefPtr.h:75 #1 0x00007f2faafc8c38 in WTF::String::utf8(WTF::ConversionMode) const (this=this@entry=0x8, mode=mode@entry=WTF::LenientConversion) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/text/WTFString.cpp:820 #2 0x00007f2faafc8caf in WTF::String::utf8() const (this=this@entry=0x8) at /usr/src/debug/webkitgtk-2.14.3/Source/WTF/wtf/text/WTFString.cpp:828 #3 0x00007f2fac8bb606 in WebCore::PasteboardHelper::fillSelectionData(WebCore::SelectionData const&, unsigned int, _GtkSelectionData*) (this=<optimized out>, selection=..., info=<optimized out>, selectionData=0x7ffe0cf4a170) at /usr/src/debug/webkitgtk-2.14.3/Source/WebCore/platform/gtk/PasteboardHelper.cpp:149 #7 0x00007f2fa6fa98eb in <emit signal 0x7f2fa8ecb032 "drag-data-get" on instance 0x55ea9be53f60 [EphyWebView]> (instance=0x55ea9be53f60, detailed_signal=detailed_signal@entry=0x7f2fa8ecb032 "drag-data-get") at gsignal.c:3487 var_args = {{gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7ffe0cf49ba0, reg_save_area = 0x7ffe0cf49ab0}} detail = 0 itype = 94466098371744 __func__ = "g_signal_emit_by_name" #4 0x00007f2fa6f8e3e5 in g_closure_invoke (closure=closure@entry=0x55ea9a3a21b0, return_value=return_value@entry=0x0, n_param_values=5, param_values=param_values@entry=0x7ffe0cf49800, invocation_hint=invocation_hint@entry=0x7ffe0cf49780) at gclosure.c:804 marshal = <optimized out> marshal_data = <optimized out> in_marshal = 0 real_closure = 0x55ea9a3a2190 __func__ = "g_closure_invoke" #5 0x00007f2fa6fa082d in signal_emit_unlocked_R (node=node@entry=0x55ea9a3a5180, detail=detail@entry=0, instance=instance@entry=0x55ea9be53f60, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe0cf49800) at gsignal.c:3673 accumulator = 0x0 emission = {next = 0x7ffe0cf49d00, instance = 0x55ea9be53f60, ihint = {signal_id = 106, detail = 0, run_type = G_SIGNAL_RUN_LAST}, state = EMISSION_RUN, chain_type = 94466098371744} class_closure = 0x55ea9a3a21b0 handler_list = <optimized out> return_accu = 0x0 accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, v_double = 0, v_pointer = 0x0}}} signal_id = 106 max_sequential_handler_number = 28184 return_value_altered = 0 #6 0x00007f2fa6fa905f in g_signal_emit_valist (instance=instance@entry=0x55ea9be53f60, signal_id=signal_id@entry=106, detail=detail@entry=0, var_args=var_args@entry=0x7ffe0cf49a68) at gsignal.c:3391 instance_and_params = 0x7ffe0cf49800 signal_return_type = <optimized out> param_values = 0x7ffe0cf49818 node = <optimized out> i = <optimized out> n_params = <optimized out> __func__ = "g_signal_emit_valist" #8 0x00007f2fa8ea315d in gtk_drag_selection_get (widget=<optimized out>, selection_data=0x7ffe0cf4a170, sel_info=<optimized out>, time=1782394, data=0x55ea9ef455b0) at gtkdnd.c:2690 info = 0x55ea9ef455b0 null_atom = 0x6a target_info = 1 #12 0x00007f2fa6fa98eb in <emit signal 0x7f2fa8f24e43 "selection-get" on instance 0x55ea9a381cc0 [GtkWindow]> (instance=instance@entry=0x55ea9a381cc0, detailed_signal=detailed_signal@entry=0x7f2fa8f24e43 "selection-get") at gsignal.c:3487 var_args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7ffe0cf4a110, reg_save_area = 0x7ffe0cf4a020}} detail = 0 itype = 94466098320528 __ Timeout exceeded: 240 seconds, killing gdb. Looks like gdb hung while generating backtrace. This may be a bug in gdb. Consider submitting a bug report to gdb developers. Please attach coredump from this crash to the bug report if you do.