20319 - NativeNotifiers are getting leaked

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Colin Blake]

I'm running with M12 code from around the middle of last week (11/24), and
I have found a situation where Native Notifiers are not getting deleted.
This is a problem for me since I am in the process of re-implementing
Native Event Queue notification on OpenVMS, and the newer, faster, mechanism
doesn't have an unlimited capacity.

To reproduce the problem, create a Composer window and then file->close it.
A "Save Changes" box will pop up, and it is at this point when a new
NativeNotifier is created. Click on "cancel". We never see
CleanupNativeNotifier get called. Go to close the Composer window again,
but again click on cancel in the popup. Another NativeNotifier is leaked.

I realise that the culprit code here is probably not in the NSPR layer, but
I had to assign the bug to someone. Sorry! Hopefully this bug will float up
until someone says "Er, that's mine".

Comment 1

[srinivas]

Reassigning the bug choffman.

Comment 2

[chris hofmann]

dp?  andy ideas?

Comment 3

[Suresh Duddi (gone)]

I would say this is either the dialog people or editor. I would start with
editor.

Comment 4

[kinmoz]

I'm not seeing this problem in my 12/14/99 WinNt build. The NativeNotifier is
being destroyed and cleaned up when I hit the cancel button.

Here is the stack trace of how it gets called:


PL_DestroyEventQueue(PLEventQueue * 0x02c30070) line 231
nsEventQueueImpl::~nsEventQueueImpl() line 63 + 12 bytes
nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsEventQueueImpl::Release(nsEventQueueImpl * const 0x02c300c0) line 84 + 129
bytes
nsWebShell::~nsWebShell() line 679 + 27 bytes
nsWebShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsWebShell::Release(nsWebShell * const 0x02c31030) line 768 + 137 bytes
GlobalWindowImpl::OpenInternal(JSContext * 0x02970920, long * 0x011e3440,
unsigned int 4, int 1, nsIDOMWindow * * 0x0012d4fc) line 2304 + 12 bytes
GlobalWindowImpl::OpenDialog(GlobalWindowImpl * const 0x02970b18, JSContext *
0x02970920, long * 0x011e3440, unsigned int 4, nsIDOMWindow * * 0x0012d4fc) line
2160
nsCommonDialogs::DoDialog(nsCommonDialogs * const 0x0299d3b0, nsIDOMWindow *
0x02970b18, nsIDialogParamBlock * 0x02c30e20, const char * 0x02ac96a8) line 302
+ 29 bytes
nsEditorShell::ConfirmWithCancel(const nsString & {...}, const nsString & {...},
const nsString * 0x0012db60, const nsString * 0x0012dac8) line 2272 + 54 bytes
nsEditorShell::CheckAndSaveDocument(nsEditorShell * const 0x029e0b90, const
unsigned short * 0x02c35070, int * 0x0012df20) line 1202 + 71 bytes
nsEditorShell::CloseWindow(nsEditorShell * const 0x029e0b90, int * 0x0012df20)
line 1414 + 57 bytes
XPTC_InvokeByIndex(nsISupports * 0x029e0b90, unsigned int 25, unsigned int 1,
nsXPTCVariant * 0x0012df20) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x01e7c7d0,
nsXPCWrappedNative * 0x029e1660, const XPCNativeMemberDescriptor * 0x02746c10,
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long *
0x011ae7c8, long * 0x0012e0d0) line 894 + 43 bytes
WrappedNative_CallMethod(JSContext * 0x01e7c7d0, JSObject * 0x0277fe08, unsigned
int 0, long * 0x011ae7c8, long * 0x0012e0d0) line 191 + 34 bytes
js_Invoke(JSContext * 0x01e7c7d0, unsigned int 0, unsigned int 0) line 665 + 26
bytes
js_Interpret(JSContext * 0x01e7c7d0, long * 0x0012e940) line 2226 + 15 bytes
js_Invoke(JSContext * 0x01e7c7d0, unsigned int 0, unsigned int 0) line 681 + 13
bytes
js_Interpret(JSContext * 0x01e7c7d0, long * 0x0012f16c) line 2226 + 15 bytes
js_Invoke(JSContext * 0x01e7c7d0, unsigned int 1, unsigned int 2) line 681 + 13
bytes
js_InternalCall(JSContext * 0x01e7c7d0, JSObject * 0x027807f0, long 41420800,
unsigned int 1, long * 0x0012f2f0, long * 0x0012f29c) line 758 + 15 bytes
JS_CallFunctionValue(JSContext * 0x01e7c7d0, JSObject * 0x027807f0, long
41420800, unsigned int 1, long * 0x0012f2f0, long * 0x0012f29c) line 2752 + 29
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x01e7bb90, void * 0x027807f0,
void * 0x02780800, unsigned int 1, void * 0x0012f2f0, int * 0x0012f2ec) line 547
+ 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x02c31c44) line 128 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x026f76c0,
nsIDOMEvent * 0x02c31c44, unsigned int 8) line 651 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x01d97440, nsEvent *
0x0012f7e0, nsIDOMEvent * * 0x0012f7ac, unsigned int 7, nsEventStatus *
0x0012f824) line 1410 + 31 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x025e59e0, nsIPresContext *
0x01d97440, nsEvent * 0x0012f7e0, nsIDOMEvent * * 0x0012f7ac, unsigned int 1,
nsEventStatus * 0x0012f824) line 2675
nsMenuFrame::Execute() line 1236
nsMenuFrame::HandleEvent(nsMenuFrame * const 0x011f01a4, nsIPresContext *
0x01d97440, nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 284
PresShell::HandleEvent(PresShell * const 0x01e3ee84, nsIView * 0x02b0f3b0,
nsGUIEvent * 0x0012fb68, nsEventStatus * 0x0012fa74) line 2608 + 38 bytes
nsView::HandleEvent(nsView * const 0x02b0f3b0, nsGUIEvent * 0x0012fb68, unsigned
int 8, nsEventStatus * 0x0012fa74, int & 0) line 841
nsView::HandleEvent(nsView * const 0x01e3dd60, nsGUIEvent * 0x0012fb68, unsigned
int 28, nsEventStatus * 0x0012fa74, int & 0) line 826
nsViewManager::DispatchEvent(nsViewManager * const 0x01dca9d0, nsGUIEvent *
0x0012fb68, nsEventStatus * 0x0012fa74) line 1678
HandleEvent(nsGUIEvent * 0x0012fb68) line 69
nsWindow::DispatchEvent(nsWindow * const 0x02b0f284, nsGUIEvent * 0x0012fb68,
nsEventStatus & nsEventStatus_eIgnore) line 421 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fb68) line 442
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3332 +
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line
3550
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 4915299, long *
0x0012fdc8) line 2632 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x008105ec, unsigned int 514, unsigned int 0, long
4915299) line 608 + 27 bytes
USER32! 77e71820()
JSDOM! 004b0063()

Comment 5

[kinmoz]

Changing product to Browser.

Comment 6

[Colin Blake]

I on 12/14 code too now, and I am still not seeing PL_DestroyEventQueue getting
called. This is on OpenVMS, which is essentially a UNIX build. Can you try this
on a UNIX-based system?

Comment 7

[Colin Blake]

Even if I set a break on nsEventQueueImpl::~nsEventQueueImpl(), it never hits.

Comment 8

[kinmoz]

I just verified in my 12/21/1999 build that PL_DestroyEventQueue() is getting
called on Linux. This may have been fixed by the Leaks landing that was made
after the M12 branch last friday (12/17/1999).

[e-mail], could you please pull the latest mozilla source from the
tip and verify that this is indeed fixed for your platform? Let me know if it is
so I can close this bug. Thanks!!!

Comment 9

[Colin Blake]

Using the released M12 code.

I get into GlobalWindowImpl::OpenInternal, but never into nsWebShell::Release.

Can you tell me which source line corresponds to the follwing in your
stack trace (there are several NSRELEASE calls):

GlobalWindowImpl::OpenInternal(JSContext * 0x02970920, long * 0x011e3440,
unsigned int 4, int 1, nsIDOMWindow * * 0x0012d4fc) line 2304 + 12 bytes

Thanks.

Comment 10

[kinmoz]

[e-mail], the fix I am talking about is *NOT* in the M12 source
release, so if that's what you are using, you will still see the problem.

The fix went into nsGlobalWindow.cpp revision 1.194, after M12 was branched, so
M12 has revision 1.193. Here's a link to the diff for [e-mail]'s fix
if you want to try it out:

http://cvs-mirror.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&file=nsGlobalWindow.cpp&root=/cvsroot&subdir=mozilla/dom/src/base&command=DIFF_FRAMESET&rev1=1.193&rev2=1.194

Comment 11

[Colin Blake]

OK, that explains it. I'll try again once I get some M13 code up and running.
That won't be until after the holidays now, but I will try.

Comment 12

[Colin Blake]

OK, with the latest M13 code I am now seeing PL_DestroyEventQueue getting
called. Consider this one done!

Comment 13

[kinmoz]

Marking this bug fixed!

Comment 14

[kinmoz]

Marking verified since both [e-mail] and I tested this.