Summary: | [GTK] Crash at WebCore::FrameView::removeChild() | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Tomas Popela <tpopela> | ||||||
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | NEW --- | ||||||||
Severity: | Normal | CC: | bugs-noreply, cgarcia, mcatanzaro, zan | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
See Also: |
https://bugzilla.gnome.org/show_bug.cgi?id=740710 https://bugzilla.redhat.com/show_bug.cgi?id=1219986 https://bugzilla.redhat.com/show_bug.cgi?id=1533470 https://bugzilla.redhat.com/show_bug.cgi?id=1701709 |
||||||||
Attachments: |
|
Description
Tomas Popela
2015-05-11 23:38:05 PDT
WebCore::FrameView::removeChild (this=0x7f74a412cc00, widget=0x0) This can't happen in trunk, since it now receives a reference, not a pointer. And the same in 2.8, so I guess this is a blocker only for wk1. (In reply to comment #1) > WebCore::FrameView::removeChild (this=0x7f74a412cc00, widget=0x0) > > This can't happen in trunk, since it now receives a reference, not a > pointer. And the same in 2.8, so I guess this is a blocker only for wk1. It can happen, but one would have to try a bit harder to dereference a null pointer into the removeChild() call. Still happening as of 2.18.4. Full backtrace attached. Truncated backtrace: Truncated backtrace: Thread no. 1 (10 frames) #0 WTF::TypeCastTraits<WebCore::FrameView const, WebCore::Widget const, false>::isType at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/page/FrameView.h:945 #1 WTF::TypeCastTraits<WebCore::FrameView const, WebCore::Widget const, false>::isOfType at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/page/FrameView.h:945 #2 WTF::is<WebCore::FrameView, WebCore::Widget> at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WTF/wtf/TypeCasts.h:59 #3 WebCore::FrameView::removeChild at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/page/FrameView.cpp:5100 #4 WebCore::ScrollView::setHasScrollbarInternal at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/platform/ScrollView.cpp:97 #5 WebCore::ScrollView::setHasHorizontalScrollbar at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/platform/ScrollView.cpp:72 #6 WebCore::ScrollView::updateScrollbars at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/platform/ScrollView.cpp:644 #7 WebCore::ScrollView::setFrameRect at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/platform/ScrollView.cpp:1011 #8 WebCore::FrameView::setFrameRect at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/page/FrameView.cpp:533 #9 WebCore::Widget::resize at /usr/src/debug/webkitgtk4-2.18.4-1.fc27.x86_64/Source/WebCore/platform/Widget.h:116 Created attachment 336671 [details]
Backtrace
We have 91 reports of this in Fedora, including 29 reports against 2.18.6. None against 2.20 yet, but that's to be expected because that is still in updates-testing. (In reply to Zan Dobersek from comment #2) > It can happen, but one would have to try a bit harder to dereference a null > pointer into the removeChild() call. My guess would be the pointer is non-null, but the FrameView has already been destroyed. (In reply to Michael Catanzaro from comment #5) > We have 91 reports of this in Fedora, including 29 reports against 2.18.6. > None against 2.20 yet, but that's to be expected because that is still in > updates-testing. > > (In reply to Zan Dobersek from comment #2) > > It can happen, but one would have to try a bit harder to dereference a null > > pointer into the removeChild() call. > > My guess would be the pointer is non-null, but the FrameView has already > been destroyed. I don't think that's possible. The FrameView is the main frame one, got in WebPage::setSize() with m_page->mainFrame().view(); Then FrameView::resize() is called which calls FrameView::setFrameRect() that protects this at the beginning, before calling ScrollView::setFrameRect() which is the one calling updateScrollbars(). Created attachment 367912 [details]
Newer backtrace
Still crashing here in 2.24.1. This time it's occurring during a call to WebCore::AccessibilityObject::updateBackingStore, but that might be just coincidence. Sadly gdb is no longer showing the value for the widget parameter: #3 WebCore::FrameView::removeChild (this=0x7f5f92e00438, widget=...) at ../Source/WebCore/page/FrameView.cpp:4959 No locals. |