523763 - valgrind - Invalid Read of size 4 in nsIDeviceContext::AppUnitsPerDevPixel() destroying view

Status: NEW

(Core :: Web Painting, defect)

Description

[Bob Clary [:bc] (inactive)]

valgrind mochitest linux mozilla-central. valgrind 3.2.1, built with --enable-valgrind, not run with --smc-check=all

After content/base/test/test_bug426308.html started the following error occurred. I can't tell which test was being torn down.

Invalid read of size 4
   at 0x69E8E72: nsIDeviceContext::AppUnitsPerDevPixel() const (nsIDeviceContext.h:284)
   by 0x6FC43F4: nsViewManager::ViewToWidget(nsView*, nsView*, nsRect const&) const (nsViewManager.cpp:1833)
   by 0x6FC5750: nsViewManager::UpdateWidgetArea(nsView*, nsIWidget*, nsRegion const&, nsView*) (nsViewManager.cpp:795)
   by 0x6FC58ED: nsViewManager::UpdateView(nsIView*, nsRect const&, unsigned) (nsViewManager.cpp:826)
   by 0x6FC38CC: nsViewManager::UpdateView(nsIView*, unsigned) (nsViewManager.cpp:584)
   by 0x6FC4B0B: nsViewManager::RemoveChild(nsIView*) (nsViewManager.cpp:1364)
   by 0x6FBE369: nsView::~nsView() (nsView.cpp:222)
   by 0x6FBBF5D: nsIView::Destroy() (nsView.cpp:292)
   by 0x6FC77D6: nsViewManager::~nsViewManager() (nsViewManager.cpp:180)
   by 0x6FC63A1: nsViewManager::Release() (nsViewManager.cpp:226)
   by 0x69D9AC1: nsCOMPtr<nsIViewManager>::~nsCOMPtr() (nsCOMPtr.h:510)
   by 0x6A0C475: DocumentViewerImpl::~DocumentViewerImpl() (nsDocumentViewer.cpp:602)
 Address 0x1186FFD4 is 4 bytes inside a block of size 88 free'd
   at 0x4004CF1: operator delete(void*) (vg_replace_malloc.c:244)
   by 0x50AF22C: nsThebesDeviceContext::~nsThebesDeviceContext() (nsThebesDeviceContext.cpp:351)
   by 0x50AE8F3: nsThebesDeviceContext::Release() (nsThebesDeviceContext.cpp:295)
   by 0x6A38D9E: nsPresContext::~nsPresContext() (nsPresContext.cpp:312)
   by 0x6A38A7E: nsPresContext::Release() (nsPresContext.cpp:325)
   by 0x6A1250D: nsCOMPtr<nsPresContext>::assign_assuming_AddRef(nsPresContext*) (nsCOMPtr.h:495)
   by 0x6A12543: nsCOMPtr<nsPresContext>::assign_with_AddRef(nsISupports*) (nsCOMPtr.h:1181)
   by 0x6A164A3: nsCOMPtr<nsPresContext>::operator=(nsPresContext*) (nsCOMPtr.h:640)
   by 0x6A0C220: DocumentViewerImpl::Destroy() (nsDocumentViewer.cpp:1612)
   by 0x6A0E6FF: DocumentViewerImpl::Show() (nsDocumentViewer.cpp:1913)
   by 0x6A340E2: nsPresContext::EnsureVisible() (nsPresContext.cpp:1599)
   by 0x6A4B679: PresShell::UnsuppressAndInvalidate() (nsPresShell.cpp:4632)

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This isn't gfx -- it's something holding on to a device context pointer after it was destroyed.  I think we have another bug on something similar, with I think a similar path through the code?  (Destroy() destroying a bunch of things, but missing a COMPtr which is then destroyed during the destructor, but which has bare pointers to things already freed since they were intended to be owned by the DocumentViewerImpl.)

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I also saw this one a while back while loading aol webmail when I was debugging bug 507457.

Comment 3

[Julian Seward [:jseward]]

(In reply to comment #1)
> This isn't gfx -- it's something holding on to a device context pointer after
> it was destroyed.  I think we have another bug on something similar, with I
> think a similar path through the code?

Bug 515799, possibly?

Comment 4

[Bob Clary [:bc] (inactive)]

This also occurs in crashtests after layout/xul/base/src/tree/src/crashtests/382444-1.html.

Comment 5

[Julian Seward [:jseward]]

I'd be inclined to close this as a dup of bug 515799.  The stack
traces aren't absolutely identical, but they are pretty darn close.