The point of the IDOM is that it performs its own memory management. The list pointer may point to the middle of a block of memory allocated by the IDOM and parceled out as needed. Releasing such a pointer could (probably would) corrupt the heap. transcode() just happens to be the first victim.
Just a guess. It doesn't hold water if this is in fact the leak that Purify was complaining about. -----Original Message----- From: Christy, Rich [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 31, 2001 10:22 AM To: '[EMAIL PROTECTED]' Subject: RE: delete[] problems with transcode Actually purify was complaining of a memory leak with the list until I deleted it. How could deleting the list cause transcode to fail internally? In fact what can you do to make transcode fail internally? Thanks, Rich -----Original Message----- From: Tinny Ng [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 31, 2001 7:47 AM To: [EMAIL PROTECTED] Subject: Re: delete[] problems with transcode Rich, I don't think it's related to transcode. There's no need to "delete list", the IDOM implementation has its own memory management. The only explicit delete application need to do is to delete the document if you are building the tree yourself. See http://xml.apache.org/xerces-c/program.html#IDOMMemMgmt for more details. Tinny "Christy, Rich" wrote: > Tinny, > > The code segment looks like this: > > const IDOM_Element* > IDOMStreamer::findElement(const char* elementName, const IDOM_Element > *parentElement) const { > > XMLCh *transcodedElement = XMLString::transcode(elementName); > IDOM_NodeList *list = > parentElement->getElementsByTagName(transcodedElement); > delete[] transcodedElement; > > const IDOM_Element *element = ((const IDOM_Element*)list->item(0)); > > // need to delete list only (destructor does not delete elements in list) > delete list; > > return element; > } > > I core dumps on the call to transcode. > > Thanks, > > Rich > > -----Original Message----- > From: Tinny Ng [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 30, 2001 4:01 PM > To: [EMAIL PROTECTED] > Subject: Re: delete[] problems with transcode > > Christy, > > Can you post more detail, e.g. how does IDOMStreamer::findElement call > transcode()? > > Thanks! > Tinny > > "Christy, Rich" wrote: > > > After downloading and installing 1.5.2 official release, I started having > > core dumps calls to XMLString::transcode. The errors appear to be > problems > > with new [] vs. delete [] given the stack trace (I've seen the > > cleanfree/realfree trace before and mismatching new[] with delete vs. > > delete[] was the problem). I'm running on Solaris 2.6 and using the IDOM > > api. > > > > I'm just curious if this is a known problem. This code seem to work fine > > with 1.5.1 version. > > > > [1] realfree(0xd970f4, 0x13c7150, 0xeeca9ce8, 0xeeca3680, 0xd970ec, > > 0x630065), at 0xeec461b4 > > [2] cleanfree(0x0, 0xeeca3680, 0xeeca9c5c, 0xeeca9cdc, 0xeeca9c60, 0x0), > > at 0xeec46a8c > > [3] _malloc_unlocked(0xd970f4, 0x18, 0x0, 0xd970ec, 0x0, 0xeeca3680), at > > 0xeec45c14 > > [4] malloc(0x16, 0x2caf8, 0x74650000, 0x7efefeff, 0xeda0a630, 0x78e5ec), > > at 0xeec45b0c > > [5] operator new(0x16, 0xeda0a658, 0xef3671e0, 0xa, 0x65, 0x78e5f6), at > > 0xef33a704 > > [6] IconvLCPTranscoder::transcode(0xb, 0x78e5ec, 0x0, 0xeda0a630, 0xa, > > 0x0), at 0xeeed4ad0 > > [7] IDOMStreamer::findElement(this = 0xa9a7e0, elementName = 0x78e5ec > > "lastUpdate", parentElement = 0xa6e1f8), line 654 in "IDOMStreamer.C" > > > > Thanks > > > > Rich Christy > > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
