Hello again and greetings to all.
I was wondering if xercex 1.1.0 has memory leaks.
Please advice me on this as to how do i take care to avoid them.
Thanks a ton in advance
Kind regards
krk
[EMAIL PROTECTED] wrote:
> You should be fine with that. The init code won't trigger more than once in
> this scenario. Though, if you *did* have this scenario, it will still be
> more efficient to mvoe the init out of the loop :-)
and [EMAIL PROTECTED] wrote:
> Yes to everything. The code samp
e
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
"MATTHEWS,HEATHER (HP-Vancouver,ex1)" <[EMAIL PROTECTED]> on
03/28/2000 03:18:51 PM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: RE: Memo
or am I misunderstanding the example?
-Heather
-Original Message-
From: Andy Heninger [mailto:[EMAIL PROTECTED]
Sent: Friday, March 24, 2000 3:00 PM
To: [EMAIL PROTECTED]
Subject: Re: Memory leaks in xerces-c_1_1.dll
Hi Alex,
You are correct. Xerces will leak if the DLL is
Thanks for attention to my novice self-educational questions that bare no
practical sence. I attach my code and jar. I have no source (perhaps, you
never include it together with jars, and I need to compile the hole tree
myself?). I know not if it preserves line number after decompilation.
The ess
c "not", ...
> > This is different from just calling Initialize multiple times, which
does
> > NOT cause leaks.
-- Andy
- Original Message -
From: "Michael Mason" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 28, 2000 1:10 AM
"But if I've got a program that's linked to the dynamic library and
doesn't do any explicit loading or unloading of libraries, the Xerces-C
lib won't get unloaded and reloaded, right? I mean something like
(functions probably all wrong, I haven't looked at the init code for a
while):
int main(v
The code
boolean readOnly = true;
deep = true;
nodeContainer.setReadOnly (readOnly, deep);
Produces the infinite loop.
java.lang.StackOverflowError
at org.apache.xerces.dom.DocumentTypeImpl.setReadOnly(DocumentTypeImpl.java:305)
at org.apache.xerces.dom.DocumentTypeImpl.setReadOnly(DocumentTy
Andy Heninger wrote:
>
> Be aware that there will be leaks if you repeatedly dynamically load and
> unload the xerces-c library. The initialization happens over each time.
> This is different from just calling Initialize multiple times, which does
> cause leaks.
But if I've got a program that's
Be aware that there will be leaks if you repeatedly dynamically load and
unload the xerces-c library. The initialization happens over each time.
This is different from just calling Initialize multiple times, which does
cause leaks.
This problem will get fixed eventually.
-- Andy
> Michael Mas
Michael Mason wrote:
>
> I'm sure someone's asked this before, but can I confirm that if I sit
> and run the initialize code over and over in the same process (which is
> dumb and avoidable), it'll realise things are set up already and just do
> nothing, rather than leaking?
Replying to myself ag
[EMAIL PROTECTED] wrote:
>
> These aren't leaks. These are setup of one time only static/global data
> that only happen once you initialize. They will not ever happen again
> within the same process and just live for the life of the process.
I'm sure someone's asked this before, but can I confir
PROTECTED]>
> This is a follow-up to the email sent 2 days ago by Steve Chuang re memory
> leaks in Xerces.
>
> Summary
> Xerces DLL allocates memory on the heap during initialization. Since the
> memory is not cleaned automatically by the DLL and the DLL provides no
> mechani
ED]>, Mike Hatalski
<[EMAIL PROTECTED]>, Mike Miele
<[EMAIL PROTECTED]>, Hatem ElSebaaly
<[EMAIL PROTECTED]>, Robert Asis <[EMAIL PROTECTED]>
Subject: Memory leaks in xerces-c_1_1.dll
Hi Andy,
This is a follow-up to the email sent 2 days ago by Stev
PROTECTED]> on 03/23/2000 11:52:18 AM
Please respond to [EMAIL PROTECTED]
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc: Robert Asis <[EMAIL PROTECTED]>, Alex Matevossian
<[EMAIL PROTECTED]>
Subject: memory leaks
To whom it may concern,
Hi Andy,
This is a follow-up to the email sent 2 days ago by Steve Chuang re memory
leaks in Xerces.
Summary
Xerces DLL allocates memory on the heap during initialization. Since the
memory is not cleaned automatically by the DLL and the DLL provides no
mechanism to release the memory explicitly
, I have a sample code that illustrates this.
Regards,
Alex.
-Original Message-
From: Andy Heninger [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 23, 2000 5:46 PM
To: [EMAIL PROTECTED]
Cc: Robert Asis; Alex Matevossian
Subject: Re: memory leaks
What you are seeing as leaks are actually
Asis" <[EMAIL PROTECTED]>; "Alex Matevossian"
<[EMAIL PROTECTED]>
Sent: Thursday, March 23, 2000 11:52 AM
Subject: memory leaks
> To whom it may concern,
>
> I'm experiencing some memory leaks. Here are all the details that I can
> provide.
> * Just by callin
To whom it may concern,
I'm experiencing some memory leaks. Here are all the details that I can
provide.
* Just by calling XMLPlatformUtils::Initialize() and doing absolutely
no parsing, I'm getting memory leaks when my test program terminates.
* I have attached a text
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 03/06/2000 08:39:53 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: memory leaks?
Hi,
I have a memory leak. I'm not sure yet if it's in the library, or
ment from the start, you can ship a product that you can be
pretty confident has no pointer errors or memory leaks at all.
http://www.onyx-tech.com
For windows there is boundschecker; I haven't tried it but was irritated it was
compiler-specific and didn't support codewarrior. I
7;t
since
that caller can also take static strings.
It happens that I have a huge number of memory leaks in my code. The text
file giving the stack traces is about 400k. I've actually been fairly careful
to
delete memory as best I could - to have that many leaks is pretty suprising.
It
> I have a memory leak. I'm not sure yet if it's in the library, or my faulty
> use of
> it.
...
> char *foo = str.transcode();
transcode() allocates space for the char* using new[]; the caller is
responsible for delete[]ing it.
This isn't clearly documented; the description of transcode(
Hi,
I have a memory leak. I'm not sure yet if it's in the library, or my faulty
use of
it.
I do something like this:
while ( not done ){
DOM_Element el = (find the element)
DOMString str = el.getAttribute( attributeName );
char *foo = str.transcode();
DoSomething( foo );
}
in my cas
[EMAIL PROTECTED] wrote:
> >Mutexes.cpp: The destructor ~XMLMutex after calling closeMutex should
> >delete fHandle.
>
> This was the only non-DOM one that I was kind of unsure of. Basically, the
> per-platform code that provides the implementation of closeMutex is
> responsible for cleaning up
>Mutexes.cpp: The destructor ~XMLMutex after calling closeMutex should
>delete fHandle.
This was the only non-DOM one that I was kind of unsure of. Basically, the
per-platform code that provides the implementation of closeMutex is
responsible for cleaning up the fHandle. Its the only one who k
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Subject: XML4C++ 1.1.0 memory leaks
I have found a few memory leaks in the XML4C++ 1.1.0 DLL. We are building
COM components under
Win32 which parse XML files. Since these COM components are loaded and
unloaded multip
I have found a few memory leaks in the XML4C++ 1.1.0 DLL. We are building
COM components under
Win32 which parse XML files. Since these COM components are loaded and
unloaded multiple times in the same process address space, minor memory
leaks tend to accumulate. To find these, I built a DLL
Your welcome, any time.
No tool, just _CRTDBG_MAP_ALLOC and friends with VC6, and the workaround
described at
http://support.microsoft.com/support/kb/articles/Q140/8/58.ASP to
get the file and line number of the leaking new. After that it was
just some brute force time with the debugger.
John
[
Thank you. They were all good catches. Did you catch them while doing
a walkthrough of the code, or did you use some tool. If so, which one?
rahul
Here are some example patches documenting a few leaks we found. Let
me know if these look ok.
These are diff'ed against the Xerces-C-src_1_0_0.zip drop. Looks like
they are still in the latest cvs version of the code at this time. We
were stuffing SAXException's into a stl container, hence the add
31 matches
Mail list logo
