T
TC
Good idea, I missed the fact that the dll is written in dotnet also. The
other option of course is to just ask for the source code
Michael- Hide quoted text -
- Show quoted text -
I'm trying to obtain the source code. That's going to be an uphill
battle.
This issue has taken an unexpected twist. Before applying any of the
solutions suggested here, I studied the code to see if I could reduce
the number of calls to the leaky component. I found that I don't need
to repeatedly create and discard any objects (Instead, I can create
persistent objects and reuse them). Also, I found I can reduce the
recurring calls to just one method (a benign one -- not the leaky
method mentioned in my original post). After applying those changes,
the leak vanished on the development computer. Yay!
Unfortunately, my tester reports that the leak is still rampant on the
test computer. We are completely baffled by this. We spent the past
day trying to find a difference in the two environments which could
explain why the leak exists on one computer, but not the other. So
far, we've come up with nothing.
In order to solve this, I suspect we will have to do a lot tedious
research, studying the system configurations, comparing precise
versions of dlls, etc. I don't think any advice from the newsgroup can
help us, but I'm posting this message just in case someone has an
inspiration and says "Of course! I know exactly what's happening...".
Thanks again for the earlier help.
-TC