WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 32381
48939
ASSERT resizing Google Maps window
https://bugs.webkit.org/show_bug.cgi?id=48939
Summary
ASSERT resizing Google Maps window
Xan Lopez
Reported
2010-11-03 11:50:29 PDT
Load google maps in a recent version of WebKit (happens at least since Monday 1st Nov.). When the load is done resize the window, you'll get an ASSERT. We have managed to reproduce it on GTK+ and Mac ports, here follows the GTK+ stack: ASSERTION FAILED: !needsLayout() (../../WebCore/page/FrameView.cpp:1999 virtual void WebCore::FrameView::paintContents(WebCore::GraphicsContext*, const WebCore::IntRect&)) Program received signal SIGSEGV, Segmentation fault. 0x00cd8770 in WebCore::FrameView::paintContents (this=0x8c6d878, p=0xbfffce94, rect=...) at ../../WebCore/page/FrameView.cpp:1999 1999 ASSERT(!needsLayout()); (gdb) bt #0 0x00cd8770 in WebCore::FrameView::paintContents (this=0x8c6d878, p=0xbfffce94, rect=...) at ../../WebCore/page/FrameView.cpp:1999 #1 0x00d7a370 in WebCore::ScrollView::paint (this=0x8c6d878, context=0xbfffce94, rect=...) at ../../WebCore/platform/ScrollView.cpp:840 #2 0x010e6427 in paintWebView (frame=0x8c58bb8, transparent=0, context=..., clipRect=..., rects=WTF::Vector of length 16, capacity 16 = {...}) at ../../WebKit/gtk/webkit/webkitwebview.cpp:617 #3 0x010e66fc in webkit_web_view_draw (widget=0x8c240a0, cr=0x2febe0) at ../../WebKit/gtk/webkit/webkitwebview.cpp:685 #4 0x080c629f in ephy_web_view_draw (widget=0x8c240a0, cr=0x2febe0) at ../../embed/ephy-web-view.c:1195 #5 0x0293c8a3 in _gtk_marshal_BOOLEAN__BOXED (closure=0x814eb48, return_value=0xbfffd090, n_param_values=2, param_values=0xb2201af0, invocation_hint=0xbfffd0ac, marshal_data=0x80c6261) at gtkmarshalers.c:85 #6 0x02ab75be in gtk_widget_draw_marshaller (closure=0x814eb48, return_value=0xbfffd090, n_param_values=2, param_values=0xb2201af0, invocation_hint=0xbfffd0ac, marshal_data=0x80c6261) at gtkwidget.c:810 #7 0x033a7f0e in g_type_class_meta_marshal (closure=0x814eb48, return_value=0xbfffd090, n_param_values=2, param_values=0xb2201af0, invocation_hint=0xbfffd0ac, marshal_data=0x90) at gclosure.c:877 #8 0x033a7bfd in g_closure_invoke (closure=0x814eb48, return_value=0xbfffd090, n_param_values=2, param_values=0xb2201af0, invocation_hint=0xbfffd0ac) at gclosure.c:766 #9 0x033c0661 in signal_emit_unlocked_R (node=0x814e9a8, detail=0, instance=0x8c240a0, emission_return=0xbfffd1cc, instance_and_params=0xb2201af0) at gsignal.c:3290 #10 0x033bf877 in g_signal_emit_valist (instance=0x8c240a0, signal_id=64, detail=0, var_args=0xbfffd2a0 "\334\322\377\277") at gsignal.c:2993 #11 0x033bfad7 in g_signal_emit (instance=0x8c240a0, signal_id=64, detail=0) at gsignal.c:3040 #12 0x02abff1d in _gtk_widget_draw_internal (widget=0x8c240a0, cr=0x2febe0, clip_to_size=1) at gtkwidget.c:5500 #13 0x02ac06a6 in gtk_widget_send_expose (widget=0x8c240a0, event=0xbfffd3d8) at gtkwidget.c:5740 #14 0x0293ae6e in gtk_main_do_event (event=0xbfffd3d8) at gtkmain.c:1678 #15 0x00183ad4 in _gdk_window_process_updates_recurse (window=0x8ccf3f0, expose_region=0x8dd5888) at gdkwindow.c:3976 #16 0x001839e2 in _gdk_window_process_updates_recurse (window=0x839fc98, expose_region=0x8d0f9e8) at gdkwindow.c:3949 #17 0x001bd292 in _gdk_windowing_window_process_updates_recurse (window=0x839fc98, region=0x8d0f9e8) at gdkwindow-x11.c:5489 #18 0x00183d74 in gdk_window_process_updates_internal (window=0x839fc98) at gdkwindow.c:4134 #19 0x00184125 in gdk_window_process_updates (window=0x839fc98, update_children=1) at gdkwindow.c:4308 #20 0x02adc362 in gtk_window_move_resize (window=0x817a008) at gtkwindow.c:7010 #21 0x02adacc7 in gtk_window_check_resize (container=0x817a008) at gtkwindow.c:6052 #22 0x033c0c9b in g_cclosure_marshal_VOID__VOID (closure=0x8174f90, return_value=0x0, n_param_values=1, param_values=0x8cf2d50, invocation_hint=0xbfffd81c, marshal_data=0x2adac79) at gmarshal.c:79 #23 0x033a7f0e in g_type_class_meta_marshal (closure=0x8174f90, return_value=0x0, n_param_values=1, param_values=0x8cf2d50, invocation_hint=0xbfffd81c, marshal_data=0x1a8) at gclosure.c:877 #24 0x033a7bfd in g_closure_invoke (closure=0x8174f90, return_value=0x0, n_param_values=1, param_values=0x8cf2d50, invocation_hint=0xbfffd81c) at gclosure.c:766 #25 0x033c0661 in signal_emit_unlocked_R (node=0x8174fc0, detail=0, instance=0x817a008, emission_return=0x0, instance_and_params=0x8cf2d50) at gsignal.c:3290 #26 0x033bf7eb in g_signal_emit_valist (instance=0x817a008, signal_id=119, detail=0, var_args=0xbfffda0c "\312GD\003\300\313\025\b\b\240\027\bh\311\025\b\001") at gsignal.c:2983 #27 0x033bfad7 in g_signal_emit (instance=0x817a008, signal_id=119, detail=0) at gsignal.c:3040 #28 0x0288be04 in gtk_container_check_resize (container=0x817a008) at gtkcontainer.c:1720 #29 0x0288ba46 in gtk_container_idle_sizer (data=0x0) at gtkcontainer.c:1608 #30 0x0016ea7b in gdk_threads_dispatch (data=0x8cf7c30) at gdk.c:487 #31 0x034263e8 in g_idle_dispatch (source=0x94567e8, callback=0x16ea36 <gdk_threads_dispatch>, user_data=0x8cf7c30) at gmain.c:4378 #32 0x034227f1 in g_main_dispatch (context=0x8138480) at gmain.c:2229 #33 0x03423aff in g_main_context_dispatch (context=0x8138480) at gmain.c:2786 #34 0x03423f54 in g_main_context_iterate (context=0x8138480, block=1, dispatch=1, self=0x8112258) at gmain.c:2864 #35 0x034246bd in g_main_loop_run (loop=0x8119368) at gmain.c:3072 #36 0x0293a6ab in gtk_main () at gtkmain.c:1321 #37 0x0806d2c1 in main (argc=1, argv=0xbfffed24) at ../../src/ephy-main.c:732 (gdb) After some investigation here's what happens: When you resize the window a redraw is scheduled by the platform. Before the draw happens we'll force any pending layout to be executed. Since the window was resized, during the postLayout phase we'll emit the resize DOM event which the google maps page connects to. In its callback the page modifies the DOM in a way that causes a new layout to be scheduled (the exact DOM method that WebKit executes internally is replaceChild), but it's not executed right away. We now proceed to the actual drawing code, which will pretty early among its checks do an ASSERT to ensure that we are not drawing if there's any layout pending. We just rescheduled one, so we'll fail that and crash.
Attachments
Add attachment
proposed patch, testcase, etc.
Antonio Gomes
Comment 1
2010-11-03 12:06:32 PDT
Related to
bug 32381
?
Xan Lopez
Comment 2
2010-11-03 12:13:23 PDT
(In reply to
comment #1
)
> Related to
bug 32381
?
Yeah, looks very much like it. I cannot understand how I didn't see this before, I'm pretty sure I have resized google maps at least once since 2009. *** This bug has been marked as a duplicate of
bug 32381
***
Xan Lopez
Comment 3
2010-11-03 12:15:49 PDT
(In reply to
comment #2
)
> (In reply to
comment #1
) > > Related to
bug 32381
? > > Yeah, looks very much like it. I cannot understand how I didn't see this before, I'm pretty sure I have resized google maps at least once since 2009. > > *** This bug has been marked as a duplicate of
bug 32381
***
Well, on second thought, I guess most probably they just changed the maps page recently and now they trigger this bug...
Daniel Bates
Comment 4
2010-11-03 13:19:42 PDT
(In reply to
comment #0
)
> Load google maps in a recent version of WebKit (happens at least since Monday 1st Nov.). When the load is done resize the window, you'll get an ASSERT. We have managed to reproduce it on GTK+ and Mac ports, here follows the GTK+ stack:
I was not able to reproduce this issue using the Mac port as of
r71254
. I can confirm this affects the Apple Windows build using
r70988
.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug