Bug 21390 – [Gtk] Linux/Gtk: GtkLauncher crashes on Acid3 (but after test 80 this time)

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Clemmitt Sigler]

Hi,

I feel like a persistent bearer of bad news :^(  Thanks to Dave Hyatt, a previous Acid3 crash was fixed under Linux/Gtk.  But now Acid3 crashes again, later on, around test 80 out of 100.  This is running trunk r37317.

This time I've actually got a backtrace! -->

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb58db8e0 (LWP 21108)]
0xb7b53abc in WebCore::ScrollView::platformRemoveChild ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
(gdb) backtrace
#0  0xb7b53abc in WebCore::ScrollView::platformRemoveChild ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#1  0xb78ef707 in WebCore::ScrollView::removeChild ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#2  0xb78f00bd in WebCore::ScrollView::setHasHorizontalScrollbar ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#3  0xb78c65bf in WebCore::FrameView::~FrameView ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#4  0xb799c9ad in WebCore::RenderPart::~RenderPart ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#5  0xb799cf40 in WebCore::RenderPartObject::~RenderPartObject ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#6  0xb799648c in WebCore::RenderObject::arenaDelete ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#7  0xb79c3199 in WebCore::RenderWidget::deref ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#8  0xb79c3a16 in WebCore::RenderWidget::destroy ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#9  0xb7727dd9 in WebCore::Node::detach ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#10 0xb76f2eae in WebCore::ContainerNode::detach ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#11 0xb771886b in WebCore::Element::detach ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#12 0xb76f2e9b in WebCore::ContainerNode::detach ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#13 0xb771886b in WebCore::Element::detach ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#14 0xb76f4d19 in WebCore::ContainerNode::removeChild ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#15 0xb7662a87 in WebCore::JSNode::removeChild ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#16 0xb7c3ae03 in WebCore::jsNodePrototypeFunctionRemoveChild ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#17 0xb7e503e6 in JSC::Machine::privateExecute ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#18 0xb7e54ead in JSC::Machine::execute ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#19 0xb7d9919f in JSC::call ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#20 0xb766b0e7 in WebCore::ScheduledAction::execute ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#21 0xb7644dae in WebCore::JSDOMWindowBase::timerFired ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#22 0xb7644f3d in WebCore::DOMWindowTimer::fired ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#23 0xb78f3bcb in WebCore::TimerBase::fireTimers ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#24 0xb78f3f07 in WebCore::TimerBase::sharedTimerFired ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#25 0xb7b54f5e in WebCore::timeout_cb ()
   from /opt/siglercm/webkit/WebKit/.libs/libwebkit-1.0.so.1
#26 0xb5b72441 in ?? () from /usr/lib/libglib-2.0.so.0
#27 0x00000000 in ?? ()

HTH.

Clemmitt

[Dave Hyatt]

Can you tell what is returning null?  Is it hostWindow()?

[Jan Alonzo]

(In reply to comment #1)
> Can you tell what is returning null?  Is it hostWindow()?
> 

Hi Dave, Yes it's hostWindow that's returning NULL. Is it possible not to have a hostWindow before remove the child? Should we check if this is the case?

[Jan Alonzo]

Created attachment 24106 [details]
patch to use the child's parent if HostWindow is null

Remove the child from its parent if HostWindow is null. This makes Gtk pass acid3 again. But is it possible to have a null HostWindow when removing a child?

[Clemmitt Sigler]

(In reply to comment #3)
> Remove the child from its parent if HostWindow is null. This makes Gtk pass
> acid3 again.

Yup, looooking goooood.  Applied to r37322 and the problem is fixed.  Webkit, the little browser engine that could :^)  Thanks very much.

Clemmitt

[Alp Toker]

I'm not too sure that making platformAddChild()/platformRemoveChild() asymmetric is a good idea. Hyatt would know better, but maybe it's best to add a null check for hostWindow() in both and to leave it at that.

Either way, looks like this is exposing a bug elsewhere, possibly the new platform scrollbar code.

[Adrien Nader]

Just for the record, gmail's standard ui (so the heavy one) triggers the same crash when opening a mail conversation. The backtrace is the same up to 20.

[Adrien Nader]

And mininova too suffer from this, and apple.com (or store.apple.com), and google video, and ... and ... and ...
In fact 75% of the websites can probably crash webkit provided the window is small enough (look at the backtraces : "Scrollbar")

[Alp Toker]

Landed in r37447. Think we'll need to look closely at the recent changes some time to make sure they're doing the right thing following the introduction of HostWindow etc.

[Jan Alonzo]

*** Bug 21240 has been marked as a duplicate of this bug. ***

[Jan Alonzo]

Comment on attachment 24106 [details]
patch to use the child's parent if HostWindow is null

Setting to r+ as Alp already r+'d it and patch already landed.