60618 2011-05-11 03:26:14 -0700 WebView::performLayeredWindowUpdate() crashes with NULL pointer 2011-08-08 12:41:39 -0700 1 1 1 Unclassified WebKit WebKit Misc. 528+ (Nightly build) PC Windows 7 RESOLVED FIXED P2 Normal --- 0 wolf.heiner bfulgham aroben bfulgham simon.fraser oldest_to_newest 401891 0 wolf.heiner 2011-05-11 03:26:14 -0700 m_backingStoreBitmap can be NULL causing ->handle() to fail. This happens when I resize (quickly?) to (0,0). I am using a sizer-div and move it quickly to the topleft corner of the window and beyond. The sizer-div calls ::MoveWindow(). The crash does not always happen. Maybe it's a timing issue. If I resize slowly, then it does not crash. This lets me assume, that it only happens, when there comes a second ::MoveWindow(width=0,height=0) after sizing to (0,0). Maybe m_backingStoreBitmap is discarded for size (0,0). WebView::performLayeredWindowUpdate() should probably have a if(m_backingStoreBitmap!=NULL), anyway. http://svn.webkit.org/repository/webkit/trunk Revision: 85004 Method: void WebView::performLayeredWindowUpdate() crashes when accessing m_backingStoreBitmap->handle() with m_backingStoreBitmap = 0 Stack trace: > WebKit_debug.dll!WebCore::RefCountedGDIHandle<HBITMAP__ *>::handle() Line 51 + 0x3 bytes C++ WebKit_debug.dll!WebView::performLayeredWindowUpdate() Line 1001 + 0x12 bytes C++ WebKit_debug.dll!WebView::WebViewWndProc(HWND__ * hWnd=0x000b0b78, unsigned int message=15, unsigned int wParam=0, long lParam=0) Line 2130 C++ user32.dll!76bcc4e7() [Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] user32.dll!76bc5f9f() user32.dll!76bcc590() user32.dll!76bc4f0e() user32.dll!76bc4f7d() ntdll.dll!77816fee() user32.dll!76bc4ec3() user32.dll!76bc1be4() user32.dll!76bbffcd() WebKit_debug.dll!WebView::repaint(const WebCore::IntRect & windowRect={...}, bool contentChanged=false, bool immediate=true, bool repaintContentOnly=false) Line 756 + 0xf bytes C++ WebKit_debug.dll!WebChromeClient::invalidateWindow(const WebCore::IntRect & windowRect={...}, bool immediate=true) Line 470 C++ WebKit_debug.dll!WebCore::Chrome::invalidateWindow(const WebCore::IntRect & updateRect={...}, bool immediate=true) Line 71 + 0x20 bytes C++ WebKit_debug.dll!WebCore::ScrollView::scrollContents(const WebCore::IntSize & scrollDelta={...}) Line 663 + 0x3f bytes C++ WebKit_debug.dll!WebCore::ScrollView::scrollTo(const WebCore::IntSize & newOffset={...}) Line 366 C++ WebKit_debug.dll!WebCore::FrameView::scrollTo(const WebCore::IntSize & newOffset={...}) Line 2109 C++ WebKit_debug.dll!WebCore::ScrollView::setScrollOffset(const WebCore::IntPoint & offset={...}) Line 351 + 0x17 bytes C++ WebKit_debug.dll!WebCore::ScrollableArea::setScrollOffsetFromAnimation(const WebCore::IntPoint & offset={...}) Line 133 + 0x13 bytes C++ WebKit_debug.dll!WebCore::ScrollAnimator::notityPositionChanged() Line 130 C++ WebKit_debug.dll!WebCore::ScrollAnimator::scrollToOffsetWithoutAnimation(const WebCore::FloatPoint & offset={...}) Line 80 + 0xf bytes C++ WebKit_debug.dll!WebCore::ScrollableArea::scrollToOffsetWithoutAnimation(const WebCore::FloatPoint & offset={...}) Line 97 + 0x21 bytes C++ WebKit_debug.dll!WebCore::ScrollView::updateScrollbars(const WebCore::IntSize & desiredOffset={...}) Line 592 C++ WebKit_debug.dll!WebCore::ScrollView::setScrollPosition(const WebCore::IntPoint & scrollPoint={...}) Line 402 C++ WebKit_debug.dll!WebCore::FrameView::setScrollPosition(const WebCore::IntPoint & scrollPoint={...}) Line 1457 C++ WebKit_debug.dll!WebCore::RenderLayer::scrollRectToVisible(const WebCore::IntRect & rect={...}, bool scrollToAnchor=false, const WebCore::ScrollAlignment & alignX={...}, const WebCore::ScrollAlignment & alignY={...}) Line 1482 C++ WebKit_debug.dll!WebCore::RenderLayer::autoscroll() Line 1586 C++ WebKit_debug.dll!WebCore::RenderBox::autoscroll() Line 660 C++ WebKit_debug.dll!WebCore::EventHandler::autoscrollTimerFired(WebCore::Timer<WebCore::EventHandler> * __formal=0x032a42b0) Line 798 + 0x21 bytes C++ WebKit_debug.dll!WebCore::Timer<WebCore::EventHandler>::fired() Line 100 + 0x23 bytes C++ WebKit_debug.dll!WebCore::ThreadTimers::sharedTimerFiredInternal() Line 112 + 0xf bytes C++ WebKit_debug.dll!WebCore::ThreadTimers::sharedTimerFired() Line 91 C++ WebKit_debug.dll!WebCore::TimerWindowWndProc(HWND__ * hWnd=0x00040a4c, unsigned int message=49797, unsigned int wParam=0, long lParam=0) Line 103 + 0x8 bytes C++ 402078 1 aroben 2011-05-11 10:21:24 -0700 Heiner, is this happening in an application that is using layered window mode? If so, which application? 402699 2 bfulgham 2011-05-11 23:26:05 -0700 Hi Adam, (In reply to comment #1) > Heiner, is this happening in an application that is using layered window mode? If so, which application? I asked Heiner to file this bug. It's happening in an application he's working on, and I wanted to open an issue to track a correction for this. 402813 3 aroben 2011-05-12 06:43:55 -0700 Sounds good. I just wanted to make sure we weren't going down the layered window path by accident. 402816 4 wolf.heiner 2011-05-12 06:55:11 -0700 I am working on my own application using WebKit.dll, etc. It is based on Brent's recent transparency patch. The transparency code is very new, has not seen may users, so it's no surprise, that some edge cases come up. 447454 5 103124 bfulgham 2011-08-05 15:50:45 -0700 Created attachment 103124 Patch 448018 6 103124 aroben 2011-08-08 08:38:46 -0700 Comment on attachment 103124 Patch When do we expect this case to get hit? It would be worth mentioning it in the ChangeLog and/or a comment. 448112 7 bfulgham 2011-08-08 11:06:13 -0700 (In reply to comment #6) > (From update of attachment 103124 [details]) > When do we expect this case to get hit? It would be worth mentioning it in the ChangeLog and/or a comment. The 'ensureBackingStore' method will not produce a backing store in cases where the window rect is zero height or zero width. I think Heiner ran into this during certain resize operations; it may be that a paint message is getting processed after the window rect has collapsed to zero height (or width). Based on his earlier comments (2011-05-11 03:26:14), it seems to trigger when the window is sized to (0,0) (which we know destroys the backing store), followed by a MoveWindow, which must be generating a paint. It might be that this could be addressed by avoiding the second paint message getting to the 'performLayeredWindowUpdate', but it seemed easiest to just check for NULL backing store and bail out early if necessary. Do you think deeper analysis of the drawing logic is warranted here? 448116 8 aroben 2011-08-08 11:08:39 -0700 (In reply to comment #7) > (In reply to comment #6) > > (From update of attachment 103124 [details] [details]) > > When do we expect this case to get hit? It would be worth mentioning it in the ChangeLog and/or a comment. > > The 'ensureBackingStore' method will not produce a backing store in cases where the window rect is zero height or zero width. I think Heiner ran into this during certain resize operations; it may be that a paint message is getting processed after the window rect has collapsed to zero height (or width). > > Based on his earlier comments (2011-05-11 03:26:14), it seems to trigger when the window is sized to (0,0) (which we know destroys the backing store), followed by a MoveWindow, which must be generating a paint. Makes sense. > It might be that this could be addressed by avoiding the second paint message getting to the 'performLayeredWindowUpdate', but it seemed easiest to just check for NULL backing store and bail out early if necessary. > > Do you think deeper analysis of the drawing logic is warranted here? I suggest we do as little work as possible when the window is 0-sized. The null-check seems fine. 448185 9 bfulgham 2011-08-08 12:41:39 -0700 Committed r92621: <http://trac.webkit.org/changeset/92621> 103124 2011-08-05 15:50:45 -0700 2011-08-08 08:38:45 -0700 Patch bug-60618-20110805155045.patch text/plain 1266 bfulgham SW5kZXg6IFNvdXJjZS9XZWJLaXQvd2luL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2Uv V2ViS2l0L3dpbi9DaGFuZ2VMb2cJKHJldmlzaW9uIDkyNTE4KQorKysgU291cmNlL1dlYktpdC93 aW4vQ2hhbmdlTG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTUgQEAKKzIwMTEtMDgtMDUg IEJyZW50IEZ1bGdoYW0gIDxiZnVsZ2hhbUB3ZWJraXQub3JnPgorCisgICAgICAgIFdlYlZpZXc6 OnBlcmZvcm1MYXllcmVkV2luZG93VXBkYXRlKCkgY3Jhc2hlcyB3aXRoCisgICAgICAgIE5VTEwg cG9pbnRlci4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lk PTYwNjE4CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAg KiBXZWJWaWV3LmNwcDoKKyAgICAgICAgKFdlYlZpZXc6OnBlcmZvcm1MYXllcmVkV2luZG93VXBk YXRlKTogQWRkIGFuIGVhcmx5CisgICAgICAgICByZXR1cm4gd2hlbiB0aGVyZSBpcyBubyBiYWNr aW5nIHN0b3JlIHRvIGJsZW5kIHdpdGguCisKIDIwMTEtMDgtMDUgIEFuZGVycyBDYXJsc3NvbiAg PGFuZGVyc2NhQGFwcGxlLmNvbT4KIAogICAgICAgICBSZW1vdmUgUGx1Z2luSGFsdGVyCkluZGV4 OiBTb3VyY2UvV2ViS2l0L3dpbi9XZWJWaWV3LmNwcAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi S2l0L3dpbi9XZWJWaWV3LmNwcAkocmV2aXNpb24gOTI0OTkpCisrKyBTb3VyY2UvV2ViS2l0L3dp bi9XZWJWaWV3LmNwcAkod29ya2luZyBjb3B5KQpAQCAtMTAwMCw2ICsxMDAwLDkgQEAgdm9pZCBX ZWJWaWV3Ojp1cGRhdGVCYWNraW5nU3RvcmUoRnJhbWVWaQogCiB2b2lkIFdlYlZpZXc6OnBlcmZv cm1MYXllcmVkV2luZG93VXBkYXRlKCkKIHsKKyAgICBpZiAoIW1fYmFja2luZ1N0b3JlQml0bWFw KQorICAgICAgICByZXR1cm47CisKICAgICBIREMgaGRjU2NyZWVuID0gOjpHZXREQyhtX3ZpZXdX aW5kb3cpOwogICAgIE93blB0cjxIREM+IGhkY01lbSA9IGFkb3B0UHRyKDo6Q3JlYXRlQ29tcGF0 aWJsZURDKGhkY1NjcmVlbikpOwogICAgIEhCSVRNQVAgaGJtT2xkID0gc3RhdGljX2Nhc3Q8SEJJ VE1BUD4oOjpTZWxlY3RPYmplY3QoaGRjTWVtLmdldCgpLCBtX2JhY2tpbmdTdG9yZUJpdG1hcC0+ aGFuZGxlKCkpKTsK