I'm using Xerces-C 1.4

I've been following this issue closely as I am running BOUNDS checker on my
app which is reporting leakage by Xerces.  

I suppose a possibility, in your case, is that Xerces does some allocation
and returns the allocated memory to the caller, who is suppose to be
responsible for freeing the memory.  'transcode()' is a good example.  It
may be possible that your DLL or EXE is having problems freeing the memory
across multiple process boundaries.  But I believe you said you weren't
making any calls to Xerces, not even a parse, so that may not be the problem
and I may be off base here.

My application is reporting memory leakage by the scanner (if I do a parse).
When I destruct my 'DOMParser', it deletes its 'XMLScanner*', which deletes
its 'ElemStack' , which has a 'StackElem**'.  'StackElem' is a struct (no
destructor) which has an entry of 'QName**'.  The '~ElemStack()' does a
"delete [] fStack[stackInd]->fChildren" which is the 'QName**'.   I see the
array of 'QName**' being deleted, but not the 'QName*' that were allocated
for each entry of the array.  I even placed a breakpoint on the '~QName()'
and it was not getting hit.

Idea?


> -----Original Message-----
> From: Wyles Eric - ewyles [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 4:26 PM
> To:   [EMAIL PROTECTED]
> Subject:      RE: Memory Leaks (code sample included)
> 
> OK, I have managed to get rid of all reports of memory leaks, but I still
> think there is either a problem or I don't completely understand something
> (probably the latter).
> 
> What I did was, in my .exe, removed all references to xerces functions and
> just passed in a hardcoded character buffer of XML to my dll. Now I do not
> get the memory leak messages.
> 
> So, I would like someone to shed some light on this if possible. The
> situation I don't understand is if I have the following 3:
> 
> 1) my exe linked against and making xerces calls
> 2) my dll linked against and making xerces calls
> 3) my exe linked against my dll (or loading at runtime with LoadLibrary)
> 
> In this case memory leaks are reported.
> 
> How can I avoid this assuming that I have no control over the exe that
> will
> be using my dll. My exe is only a test application; the dll is the actual
> product I'm working on and I may or may not have control over what the
> applications that use my dll will do.
> 
> Thanks,
> Eric
> 
> 
> -----Original Message-----
> From: Erik Schroeder [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 2:51 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Memory Leaks (code sample included)
> 
> 
> Hi, 
> This may not provide any more information, but it would be interesting to
> note what happens if you move the XMLPlatformUtils::Initialize() and
> XMLPlatformUtils::Terminate() calls into "MyXML.DLL".  Then, in the EXE,
> call whatever function in "MyXML.DLL" calls XMLPlatformUtils::Initialize()
> prior to doing _anything_ related to Xerces - including declaring
> variables
> of types that are part of Xerces (DOM_DOMImplementation)...  IOW, make
> sure
> that XMLPlatformUtils::Initialize() is called prior to any constructors
> within Xerces, etc...
> 
> HTH,
> 
> Erik
> 
> -----Original Message-----
> From: Wyles Eric - ewyles [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 2:42 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Memory Leaks (code sample included)
> 
> 
> Thanks for the suggestion, but it didn't seem to have any effect. I'm
> still
> getting reports of leaks.
> 
> I don't know if this will trigger any ideas, but I moved my FreeLibrary to
> before my Terminate() call and that resulted in even more leaks being
> reported by VC++.
> 
> 
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 2:25 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Memory Leaks (code sample included)
> 
> 
> 
> Have you tried putting the DOM_Document into an inner scope?  I believe
> the
> Xerces shutdown code will not free things if there are reference counts.
> In particular, I think DOMStringHandles are not freed.  Try this:
> 
> int main (void)
> {
>      HMODULE hDllHandle = NULL;
>      DOM_DOMImplementation          impl;
> 
>      hDllHandle = LoadLibrary("myxml.dll"); // this one causes a leak to
> be
> reported
> //         hDllHandle = LoadLibrary("mynonxml.dll"); // this one is ok
> 
>       XMLPlatformUtils::Initialize();
> 
>      {
>           DOM_Document doc = impl.createDocument(
>                                           0,
>                                           "Input",
>                                           DOM_DocumentType());
>      }
> 
>      XMLPlatformUtils::Terminate();
> 
>      FreeLibrary(hDllHandle);
> 
>      return 0;
> }
> 
> All Xerces objects should be destroyed before you attempt th call
> XMLPlatformUtils::Terminate().
> 
> Dave
> 
> 
> 
>  
> 
>                     Wyles Eric -
> 
>                     ewyles               To:
> "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>    
>                     <Eric.Wyles@a        cc:     (bcc: David N
> Bertoni/CAM/Lotus)                                 
>                     cxiom.com>           Subject:     RE: Memory Leaks
> (code
> sample included)                     
>  
> 
>                     06/07/2001
> 
>                     02:05 PM
> 
>                     Please
> 
>                     respond to
> 
>                     xerces-c-dev
> 
>  
> 
>  
> 
> 
> 
> 
> In that case though, why would I not see this if I run my application
> without loading the dll? Or even if I load a different dll that isn't
> using
> the xerces libraries?
> 
> I'm not quite sure I understand what is going on here.
> 
> Thanks,
> Eric
> 
> 
> -----Original Message-----
> From: Dean Roddey [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 12:26 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Memory Leaks (code sample included)
> 
> 
> Xerces faults in some static data. These can show up as memory leaks to
> some
> tools, but they are really just static stuff that is faulted in on first
> use, but never released until the program ends. If you really want to test
> it, load the DLL, do an initital dummy parse, then take a memory snap shot
> and check again just before you call terminate. The first parse will cause
> all of the lazy faulting in, so if you take a snapshot after that,
> anything
> that shows up in the exit snap shot is a lot more likely to be a
> legitimate
> leak.
> 
> --------------
> Dean Roddey
> Software Geek Extraordinaire
> Portal, Inc
> [EMAIL PROTECTED]
> 
> 
> 
> -----Original Message-----
> From: Wyles Eric - ewyles [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, June 07, 2001 9:47 AM
> To: '[EMAIL PROTECTED]'
> Subject: Memory Leaks (code sample included)
> 
> 
> Hi,
> 
> I'm having a problem with memory leaks under xerces c++ 1.4.0 on Windows
> NT
> using Visual C++ 6.0. I have two different modules using the xerces api.
> 
> 1) A very small test application that I have written (code below)
> 2) A dll that is called by this test application, but will eventually be
> called by other users (let's call this one 'myxml.dll')
> 
> Both of these are linked against the xerces libraries.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to