Re: DirectShow heap memory leak

Tech-Archive recommends: Speed Up your PC by fixing your registry

From: Michael Schwab (michael.schwab_at_cobecv.com)
Date: 01/11/05 

Date: Tue, 11 Jan 2005 15:39:12 -0700

Looks like you guys have been running with this thread on your own for
awhile! :-)

As you might have noticed in my "How to increase heap memory for malloc()?"
thread, I'm now using GlobalMemoryStatus() to figure out how much of my 32
Mb application address space is available (AvailVirtual), which is not all
heap space.

Anyway, yes, the 4-line example below does run out of memory eventually.
Since it eats about 1 Mb of the AvailVirtual number each time I run it, I
get about as many runs of the loop as I have Mb available (i.e. 3 to 6
times), before it runs out of memory.

But I've now been enumerating heaps, modules, threads, and processes, and I
know there's very little increase in heap space (and no increase in modules
loaded or space) each time I do the CoCreateInstance loop. However, every
time I run the loop it creates a new thread (priority 248), and then leaves
it running! So if I run it 6 times I now have 6 extra threads in my
process! I don't know if a thread takes a Mb of address space, but it does
seem to in this case!

Anyway, as I've said in my other thread, I've given up on playing movies in
my main process, since I have so little free space even before trying to
play a movie, not to mention this memory leak problem. I'm going to spawn a
new process (with CreateProcess) to play a movie, which will then kill
itself when the movie is done. That should give the movie it's own 32 Mb
address space, and should remove all memory and threads when it exits.

However, I know little about inter-process communication, and I'm afraid the
movie window (being smaller than my main app's window) will jump behind the
main window if the user touchs the main window showing around the movie. Is
there a way to "bring to top" one process over the entire system?

As usual, thanks for your help,
Michael Schwab

"Thore Karlsen [MVP DX]" <sid@6581.com> wrote in message
news:5j2ut0lm4vfg7bd62hci7fho33kqso19qj@4ax.com...
> On Fri, 7 Jan 2005 14:56:44 -0700, "Michael Schwab"
> <michael.schwab@cobecv.com> wrote:
>
> >Working backwards is a great idea - here goes:
> >
> >- Already had the pVidWin stuff commented out.
> >- Commented out the Run() and the infinite wait - still have the memory
> >leak.
> >- Commented out the Stop() and the RenderFile() - still have the memory
> >leak.
> >- Commented out the QueryInterface() for pControl and pEvent, and also
their
> >Release calls - still have the memory leak.
> >- Commented out the CoCreateInstance() and pGraph->Release() calls - no
more
> >memory leak! (Not surprising because the CoInitialize wasn't using any
heap
> >space anyway, and that's all that was left).
> >- Uncommented the CoCreateInstance() call but left the pGraph->Release()
> >call commented out - now the memory doubles to 2.097 Mb, which is the
amount
> >that the CoCreateInstance() call usually takes.
> >
> >So for some reason the pGraph->Release() is only freeing up exactly half
the
> >space that CoCreateInstance() has allocated. And calling
pGraph->Release()
> >doesn't help, and sometimes crashes it (especially under WinXP).
> >
> >So what's wrong with my CoCreateInstance() call? Is it that pGraph is a
> >local (stack?) variable?
>
> Let me see if I understand correctly. This example would produce a
> memory leak:
>
> CoInitialize();
> CoCreateInstance(... &pGraph);
> pGraph->Release();
> CoUninitialize();
>
> Is that what you are saying? This leaks when absolutely no other code is
> executed? If that's the case, there's something seriously wrong with
> your system. :)
>
> --
> New to newsgroups? Read: http://dev.6581.com/newsgroups.html

Relevant Pages

  • Re: DirectShow heap memory leak
    ... As you might have noticed in my "How to increase heap memory for malloc?" ... Anyway, yes, the 4-line example below does run out of memory eventually. ... play a movie, not to mention this memory leak problem. ... movie window will jump behind the ...
    (microsoft.public.windowsce.embedded.vc)
  • Re: Lcc-win32 extensions to C
    ... compiled with a C++ compiler or a C compiler. ... Yes, but if you do not use GC, you allocate more memory than needed to ... Using a non-GC'ed heap+ a GC'ed heap requires also more memory... ... Collector, since GC technologies are much more advanced than simple ...
    (comp.std.c)
  • Re: Huge pages and small pages. . .
    ... you need to have them cached in the TLB; if the TLB runs out of ... >>> low end of the heap, until someone figures out a way to tell the system ... >> causing them to be COW'd to real memory. ... I believe the swapper will kill them fast once you have ...
    (Linux-Kernel)
  • Re: Help wanted - problems with heap
    ... Memory pressure, because of limited heap size. ... identified that by failures to allocate memory. ... Any pointers as to work out what is happening would be welcome. ...
    (rec.games.roguelike.development)
  • RE: Defeating Microsoft Windows XP SP2 Heap protection
    ... Fact is XP SP2 is still far less likely to be vulnerable to buffer overflow ... > than the memory buffer allocated to hold it. ... > the operating system is now more careful to reduce both stack and heap ... > Execution Protection ...
    (microsoft.public.windowsxp.general)