If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

NEW
Unassigned

Status

()

Core
Layout: View Rendering
8 years ago
8 years ago

People

(Reporter: bc, Unassigned)

Tracking

({valgrind})

Trunk
x86
Linux
valgrind
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
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)
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.)
Component: Graphics → Layout: View Rendering
QA Contact: thebes → layout.view-rendering
I also saw this one a while back while loading aol webmail when I was debugging bug 507457.
(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?
(Reporter)

Comment 4

8 years ago
This also occurs in crashtests after layout/xul/base/src/tree/src/crashtests/382444-1.html.
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.
You need to log in before you can comment on or make changes to this bug.