Hi, there are a lot of event handlers - I don't know if any are connected to
the xmldoc, but whoever coded the system certainly got a bit excited about
them.
Do you know if event handlers are treated differently by the clr? It's
weird - if I have a weak reference, the object is destroyed (so there can be
no other references). However, if I have a normal reference, and null it,
the object hangs around - implying there are other references.
Thanks for the offer of looking at the code, but I don't think I can get
any.
"Mark R. Dawson" <Ma*********@discussions.microsoft.com> wrote in message
news:47**********************************@microsof t.com...
Hi Ian,
can you post a code example showing the problem, that would probably lead
to someone seeing the issue. The only way the CLR would run out of memory
is
if the object still has a reference to it somewhere in the app so that it
can't be GCed, so something in your orignal code must be holding a
reference
to this object. Did you add event handlers that listen to events in the
XMLDocument?
Mark.
--
http://www.markdawson.org
"ian" wrote:
Hi, I've got the weirdest garbage collection problem - I'd appreciate any
advice you've got.
1. A class 'X' in a system I'm working on contains a reference to an
XmlDocument, populated via LoadXML.
2. Objects of type X are reused alot so different XML is loaded numerous
times.
3. If I keep this reference, the system looses more and more memory until
it
hangs (> a gig of memory). If I replace this reference with a
WeakReference
that holds the XMLDocument, my memory stays reasonably low and constant.
Can anyone understand this behaviour? I think it's safe to assume the
WeakReference is the only reference to the XML doc as otherwise the GC
wouldn't kill it. But then, if this is the only reference then why isn't
the
memory being released when the XML is replaced normally?
Please don't suggest re-architecting the system - it's a mess, and
there's
nothing I can do about it.
Cheers for any help.
