Ok, I think this problem might need a different pair of eyes looking
at it or a different approach. I figured out where the handle leak is
coming from and fixed that problem, but there is a memory leak of
about 24-32Kb per call to RexxStart() that's got me completely
puzzled. I've set break
On Mon, Jul 6, 2009 at 11:05 AM, Rick McGuireobject.r...@gmail.com wrote:
Ok, I think this problem might need a different pair of eyes looking
at it or a different approach. I figured out where the handle leak is
coming from and fixed that problem, but there is a memory leak of
about 24-32Kb
No, RexxStart does not cause a new thread to be spawned. It runs on
the same thread as the caller. The path for something like the hello
world example they provided is very short, and I've traced most of
that path looking for potential problems. I have managed to eliminate
a number of suspects.
Rick,
I found this link which looks useful, to me. It talks about
pinpointing the location of memory leaks using Visual Studio and the
debugger:
http://msdn.microsoft.com/en-us/library/e5ewb1h3(VS.71).aspx
It is actually for Visual Studio .Net, and I can't find a counterpoint
in the VS 2005
Feel free to use my malloc/free replacements in the decNumber package if
they might help (free to use -- MIT/ICU licence). Basically counts all
bytes allocated (and freed), also puts a fence around the allocated
storage and checks not tramped on. Turned on and off by #define malloc()
and
On Mon, Jul 6, 2009 at 11:51 AM, Mark Miesfeldmiesf...@gmail.com wrote:
I found this link which looks useful, to me. It talks about
pinpointing the location of memory leaks using Visual Studio and the
debugger:
http://msdn.microsoft.com/en-us/library/e5ewb1h3(VS.71).aspx
Well, as soon as I
On Mon, Jul 6, 2009 at 11:05 AM, Rick McGuireobject.r...@gmail.com wrote:
Ok, I think this problem might need a different pair of eyes looking
at it or a different approach. I figured out where the handle leak is
coming from and fixed that problem, but there is a memory leak of
about 24-32Kb
On Mon, Jul 6, 2009 at 1:02 PM, Mark Miesfeldmiesf...@gmail.com wrote:
On Mon, Jul 6, 2009 at 11:05 AM, Rick McGuireobject.r...@gmail.com wrote:
Ok, I think this problem might need a different pair of eyes looking
For just a quick test, in the CvHello.cpp example sent by the bug
opener, I
I'm starting to think this might not be a real memory leak, but rather
an artifact of how the taskmanager is reporting the working set size.
I'm seeing the same behavior you do of it stabilizing around 13Mb. I
was able to selectively comment out bits to reduce it down to a small
window that still
On Mon, Jul 6, 2009 at 3:40 PM, Rick McGuireobject.r...@gmail.com wrote:
I checked a few additional items, and this merely confirmed my
suspicions. The initial object heap allocation is 8Mb, plus the
restored image is close to 1Mb. That's 9Mb of memory that we allocate
up front, but the
10 matches
Mail list logo
