Open
Bug 523763
Opened 15 years ago
Updated 2 years ago
valgrind - Invalid Read of size 4 in nsIDeviceContext::AppUnitsPerDevPixel() destroying view
Categories
(Core :: Web Painting, defect)
Tracking
()
NEW
People
(Reporter: bc, Unassigned)
Details
(Keywords: valgrind)
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.
Comment 3•15 years ago
|
||
(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•15 years ago
|
||
This also occurs in crashtests after layout/xul/base/src/tree/src/crashtests/382444-1.html.
Comment 5•15 years ago
|
||
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.
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•