Closed Bug 48190 Opened 24 years ago Closed 24 years ago

View manager destruction creates instances

Categories

(Core :: Web Painting, defect, P2)

Other
All
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: dp, Assigned: kmcclusk)

References

Details

(Keywords: memory-leak, Whiteboard: [nsbeta3+][HAVEFIX])

Creation of objects on destruction of xpcom prohibited. View manager seems to
want to create rendering context on destruction which is triggered by xpcom's
destruction.

(gdb) #0  nsComponentManagerImpl::CreateInstance (this=0x80645e8,
aClass=@0x41bd5624, aDelegate=0x0, aIID=@0x4005fe40, aResult=0xbffff444) at
nsComponentManager.cpp:1222
#1  0x40111954 in nsComponentManager::CreateInstance (aClass=@0x41bd5624,
aDelegate=0x0, aIID=@0x4005fe40, aResult=0xbffff444) at nsRepository.cpp:81
#2  0x41bc49e5 in nsViewManager2::~nsViewManager2 (this=0x8135e20, __in_chrg=3)
at nsViewManager2.cpp:179
#3  0x41bc50c8 in nsViewManager2::Release (this=0x8135e20) at nsViewManager2.cpp:266
#4  0x4193da4c in ?? () from
/home/dp/build.debug/mozilla/dist/bin/components/libgklayout.so
#5  0x418cca91 in ?? () from
/home/dp/build.debug/mozilla/dist/bin/components/libgklayout.so
#6  0x418cc332 in ?? () from
/home/dp/build.debug/mozilla/dist/bin/components/libgklayout.so
#7  0x40f05d66 in ?? () from
/home/dp/build.debug/mozilla/dist/bin/components/libdocshell.so
(More stack frames follow...)
Nominating for nsbeta3 to be on the safe side. I dont know the impact of this error.
Severity: normal → major
Hardware: PC → Other
Keywords: nsbeta3
added [NEEDINFO] to status whiteboard. Need to determine how dangerous this bug 
really is.

It creates a rendering context to destroy 3 global drawing surfaces which need 
to be cleaned up when the last viewmanager goes away. The rendering context has 
a method for destroying the drawing surfaces.

I need to see if it is possible to cleanly destroy the drawing surfaces without 
using a rendering context.


Status: NEW → ASSIGNED
Whiteboard: [NEEDINFO]
Target Milestone: --- → M19
FWIW, the instances never get created due to a check that was put in so I don't 
think it could be called dangerous to XPCOM.  Whether it is dangerous to the 
caller not to really create the objects in question is another matter.
Ray, thanks the info.

I confirmed the following in the debugger:

When the last viewmanager2 instance is destroyed we leak (4) global 
nsDrawingSurfaces and their associated data,  because the creation of the 
nsRenderingContext is supressed when XPCOM is shutdown.
 
This is large memory leak on shutdown but I don't think its very serious, unless 
it is making it difficult to determine where other leaks are. All of the memory 
is returned by OS anyway. 

Marking nsbeta3- and adding mlk keyword. Clearing [NEEDSINFO]. Changing severity 
to normal

Adding Jud to CC list. 
Severity: major → normal
Keywords: mlk
Whiteboard: [NEEDINFO] → [nsbeta3-]
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 
Target Milestone: M19 → Future
Are we sure this wont be a leak for win98 also. I have heard horror stories of 
win98 resource leaks.
Your right it will cause a resource leak. 4 DC's and 4 HBITMAP handles on 
WIN98/WIN95)

Changing OS from Linux to ALL.

Setting priority to P2.

Changing from nsbeta3- to nsbeta3+ based on resource leak on WIN95/WIN98.
OS: Linux → All
Priority: P3 → P2
Whiteboard: [nsbeta3-] → [nsbeta3+]
Target Milestone: Future → M18
Have fix in my tree. 
Whiteboard: [nsbeta3+] → [nsbeta3+][HAVEFIX]
Fixed in 8-17-2000 2:33PM build

Chris this is a code level change.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Yeah! now once the other instance of this is fixed, we can turn ON the assert 
for everyone (not just me). Thanks kevin.
Marking verified per last comments.
Status: RESOLVED → VERIFIED
*** Bug 41988 has been marked as a duplicate of this bug. ***
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.