146872 - MLK: Memory leak of 640 bytes from 1 block allocated in CEnumFormatEtc::CEnumFormatEtc(DWORD)

Status: RESOLVED WORKSFORME

(Core :: XUL, defect, P1)

Description

[[e-mail] (gone - use [e-mail] instead)]

Build ID: latest trunk Windows 2000 under Purify.

Summary: [W] MLK: Memory leak of 640 bytes from 1 block allocated in 
CEnumFormatEtc::CEnumFormatEtc(DWORD)

Steps to Reproduce:

1. Set about:blank as your homepage.
2. Launch mozilla.
3. Drag the leftmost link on the Personal Toolbar all the way to the rightmost 
position on the Toolbar and drop it.

[W] MLK: Memory leak of 640 bytes from 1 block allocated in 
CEnumFormatEtc::CEnumFormatEtc(DWORD)
        Distribution of leaked blocks
               640 bytes from 1 block of 640 bytes (0x08e689c0) 
        Allocation location
            new(UINT)      [MSVCRT.DLL]
            CEnumFormatEtc::CEnumFormatEtc(DWORD) [Ienumfe.cpp:86]
                  mCurrentInx = 0;
                  mNumFEs     = 0;
                  mMaxNumFEs  = aMaxFE;
             =>   mFEList     = new FORMATETC[(UINT)aMaxFE];
                }
                
                
            ???            [ip=0x08e55d10]
            nsDataObj::nsDataObj(void) [nsDataObj.cpp:90]
                  mTransferable   = nsnull;
                  mDataFlavors    = new nsVoidArray();
                
             =>   m_enumFE = new CEnumFormatEtc(32);
                  m_enumFE->AddRef();
                
                }
            nsClipboard::CreateNativeDataObject(nsITransferable *,IDataObject * 
*) [nsClipboard.cpp:127]
                  // Create our native DataObject that implements
                  // the OLE IDataObject interface
                  nsDataObj * dataObj;
             =>   dataObj = new nsDataObj();
                  dataObj->AddRef();
                
                  // No set it up with all the right data flavors & enums
            nsDragService::InvokeDragSession(nsIDOMNode *,nsISupportsArray 
*,nsIScriptableRegion *,UINT) [nsDragService.cpp:122]
                    anArrayTransferables->GetElementAt(0, getter_AddRefs
(supports));
                    nsCOMPtr<nsITransferable> trans(do_QueryInterface
(supports));
                    if ( trans ) {
             =>       if ( NS_FAILED(nsClipboard::CreateNativeDataObject(trans, 
&itemToDrag)) )
                        return NS_ERROR_FAILURE;
                    }
                  } // else dragging a single object
            XPTC_InvokeByIndex [xptcinvoke.cpp:105]
                        mov     eax,methodIndex
                        shl     eax,2               // *= 4
                        add     edx,eax
             =>         call    [edx]               // stdcall, i.e. callee 
cleans up stack.
                        mov     esp,ebp
                        pop     ebp
                        ret
            XPCWrappedNative::CallMethod
(XPCCallContext&,CallMode::XPCWrappedNative) [xpcwrappednative.cpp:1994]
                
                        // do the invoke
                        invokeResult = XPTC_InvokeByIndex(callee, vtblIndex,
             =>                                           paramCount, 
dispatchParams);
                        // resume non-blocking JS operations now
                    }
                
            XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *) 
[xpcwrappednativejsops.cpp:1266]
            js_Invoke      [jsinterp.c:788]
            js_Interpret   [jsinterp.c:2743]
            js_Invoke      [jsinterp.c:805]
            js_InternalInvoke [jsinterp.c:880]
            JS_CallFunctionValue [jsapi.c:3424]
            nsJSContext::CallEventHandler(void *,void *,UINT,void *,int *,int) 
[nsJSEnvironment.cpp:1042]
            nsJSEventListener::HandleEvent(nsIDOMEvent *) 
[nsJSEventListener.cpp:182]
            nsEventListenerManager::HandleEventSubType(nsListenerStruct 
*,nsIDOMEvent *,nsIDOMEventTarget *,UINT,UINT) [nsEventListenerManager.cpp:1221]
            nsEventListenerManager::HandleEvent(nsIPresContext *,nsEvent 
*,nsIDOMEvent * *,nsIDOMEventTarget *,UINT,nsEventStatus *) 
[nsEventListenerManager.cpp:2043]
            nsXULElement::HandleDOMEvent(nsIPresContext *,nsEvent *,nsIDOMEvent 
* *,UINT,nsEventStatus *) [nsXULElement.cpp:3446]
            nsXULElement::HandleDOMEvent(nsIPresContext *,nsEvent *,nsIDOMEvent 
* *,UINT,nsEventStatus *) [nsXULElement.cpp:3464]

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

dbaron, I'm not sure if this is related to bug 114171.

Comment 2

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

It seems like it would be impossible for this array to leak without leaking the 
CEnumFormatEtc object as well.  Furthermore, I think bug 114171 is unlikely to 
show up in Purify since it's rooted by a global.

Comment 3

[rods (gone)]

Well, certainly the descructor of nsDataObj is not being called from what I can
tell.

Comment 4

[Stephen Donner [:stephend] Not actively reading bugmail]

David, see also bug 146875 for a leak that Purify was reporting.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Still reproducible?

Comment 6

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

Possibly related to fixed bug 414482.

Comment 7

[Jim Mathies [:jimm]]

WFM in trunk - 

 => mAllocCount:          40546
 => mReallocCount:         4458
 => mFreeCount:           40546
 => mShareCount:          39182
 => mAdoptCount:           5407
 => mAdoptFreeCount:       5407

Comment 8

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

(In reply to comment #7)
> WFM in trunk - 
> 
>  => mAllocCount:          40546
>  => mReallocCount:         4458
>  => mFreeCount:           40546
>  => mShareCount:          39182
>  => mAdoptCount:           5407
>  => mAdoptFreeCount:       5407

If those numbers are what you're using to mark it worksforme, you didn't test it correctly, since those numbers are allocation statistics for string buffers.

Comment 9

[Jim Mathies [:jimm]]

(In reply to comment #8)
> (In reply to comment #7)
> > WFM in trunk - 
> > 
> >  => mAllocCount:          40546
> >  => mReallocCount:         4458
> >  => mFreeCount:           40546
> >  => mShareCount:          39182
> >  => mAdoptCount:           5407
> >  => mAdoptFreeCount:       5407
> If those numbers are what you're using to mark it worksforme, you didn't test
> it correctly, since those numbers are allocation statistics for string buffers.

Yeah sorry that was worthless info. For leak checking I'm using AQTime's allocation profiler. It's not showing any leaks for CEnumFormatEtc for this test.