Memory leak when using Xerces C++

[Stephan Irrgang]

Hi,

I found a memory leak when using Xerces C++ XML Parser in error cases (e.g. file not found). I reported this problem to Xerces (project within Apache Software Foundation), but got a response indicating that this is not a bug in Xerces, but in HP-UX.

More information can be found here
http://issues.apache.org/jira/browse/XERCESC-1486

I verified the memory leaks with both purify and wdb's built-in memory checker. Both report the same problem. Attached you can find the entire source code (just a few lines).

Question is: has somebody heard about similar memory leaks?

My environment:
HP-UX B.11.11 U 9000/800
aCC: HP ANSI C++ B3910B A.03.57
Xerces C++ 2.6 (available here http://xml.apache.org/xerces-c/download.cgi)

Any help is highly appreciated!

Regards,
Stephan

[Steve Steel]

Hi

1)check the source of the leak via

ftp://eh:spear9@hprc.external.hp.com/memory.htm

2)Make sure your patches are up to date since these things are getting fixed regularly.

3)This sounds like a bug caused by the way Xerxes accesses HP

Steve Steel

[Stephan Irrgang]

Hi,

thanks Steve, now I know that Data VSS memory area is growing. However, I guess that doesn't help me much, does it?

Reason for the memory leak is that memory allocated in an exception object is not released; somehow the destructor of that exception object is not called. I haven't read anything in the patch database about that issue, so I don't know whether updating to latest patch-level will help. Furthermore, it's not that easy to install patches in a big organization, where only few have root privileges ;-)

On the comment that this an error in how Xerces is accessing HP: I guess I have to disagree on that. I had a look at the source code, and it looks ok: just an exception, which is thrown, and which is obviously not destroyed properly - on HP-UX, that is.

Any other ideas?

Stephan

[Stephen Keane]

Just an observation, should you really be throwing a local variable? (chBuffer in myCallbackHandler_c)

[Stephan Irrgang]

I don't see a reason why not to throw a local variable. Moreover, it's not that character buffer, which isn't destroyed correctly, it's the SAXParseException, which is thrown somewhere else. All that stuff (throwing the exception, catching it, and passing it to the registered error handler myCallbackHandler_c) is implemented within Xerces C++ parser.

[Steve Steel]

Hi


What is your patch level. There are lots of fixes in the latest ones

example
Patch Name: PHKL_33372

Patch Description: s700_800 11.11 Cumulative VM, Psets, Preemption, PRM, MRG
vhand is not paging out large pages and as a result system
hangs under memory pressure.

PHNE_33159
s700_800 11.11 cumulative ARPA Transport patch
Memory leak when using socketpair(2) call on
AF_UNIX domain sockets.


Steve Steel



We could be fishing for a known problem




Steve Steel

[Dennis Handly]

>Attached you can find the entire source code

Unfortunately the leak is in the Xerces code and not in the example you provided.

I did find a similar leak in EH exceptions but that was on Integrity only and with a 7+ year old aCC5 compiler.

MemoryManagerImpl::allocate(unsigned long) [libxerces-c.sl.26.0]

XMLException::XMLException(const xercesc_2_6::XMLException &)%2 [libxerces-c.sl.26.0] IGXMLScanner::scanReset(const xercesc_2_6::InputSource &) [libxerces-c.sl.26.0]

>Reason for the memory leak is that memory allocated in an exception object is not released; somehow the destructor of that exception object is not called.

Basically what is scanReset doing with this XMLException object and does the destructor clean up what allocate allocated?

>I had a look at the source code: just an exception, which is thrown, and which is obviously not destroyed properly

It would help to have a snip of that.  Also, do you know where it caught?

>should you really be throwing a local variable? (chBuffer in myCallbackHandler_c)

That's correct, that's illegal.  While you can throw local variables, you can't throw a pointer to them.

>I don't see a reason why not to throw a local variable.

Because the buffer will be out of scope.  While that works on PA-RISC (since the exception object is allocated in that same frame), it fails on Integrity.

>All that stuff (throwing the exception, catching it, and passing it to the registered error handler myCallbackHandler_c) is implemented within Xerces C++ parser.

And that's the code that needs to be investigated.

Is SAXParseException derived from XMLException?

>What is your patch level. There are lots of fixes in the latest ones

These are not aC++ runtime patches.