Re: memory leaks when I resize window

From: Phil Taylor (philipt_at_private-citizen-sorta.com)
Date: 10/01/04 

Date: Fri, 1 Oct 2004 11:37:29 -0700

use the break on alloc-id cpl feature and track down what D3D still thinks
is allocated.

it looks like you arent destroying all resources.

"Hanna-Barbera" <hb@nulllink.com> wrote in message
news:%23XpFD88pEHA.1152@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> I'm using DX9c. VC++6. I have installed the specific d3dx9.lib for VC++6
> I have the usual code for destroying all d3d resources, then the d3d
> surface
> and device when a window resize occurs,
> and then I recreate everything.
>
> I tried this in both when getting WM_SIZE and WM_EXITSIZEMOVE but in both
> cases I get leaks.
> This is what the output window in VC++ displays when I shut down the my
> application. It only displays it when I shutdown and not during resizing.
> Also, someone else who is testing and various machines running WinXP says
> he
> gets crashes on some machines, but not others.
> I'm on Win2k, Cat 4.8, Radeon 9700 and I don't get crashes. I have no idea
> what the other person is testing on but says they run winXP with DX9c
> runtime.
>
> Direct3D9: (ERROR) :Memory still allocated! Alloc count = 116
> Direct3D9: (ERROR) :Current Process (pid) = 00000570
> Direct3D9: (ERROR) :Memory Address: 00c0422c lAllocID=310 dwSize=000047f8,
> ReturnAddr=011534c8 (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 00c08a64 lAllocID=318 dwSize=00001224,
> ReturnAddr=0114c2cb (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 013f8814 lAllocID=319 dwSize=00000008,
> ReturnAddr=0114c36b (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 0136075c lAllocID=320 dwSize=00000780,
> ReturnAddr=01151741 (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 01360064 lAllocID=329 dwSize=000006bc,
> ReturnAddr=0115f3b3 (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 013f900c lAllocID=331 dwSize=000015f0,
> ReturnAddr=011545bd (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 013f885c lAllocID=333 dwSize=00000008,
> ReturnAddr=011546ee (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 01360f14 lAllocID=335 dwSize=00003508,
> ReturnAddr=011534c8 (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 00c09cbc lAllocID=336 dwSize=00000198,
> ReturnAddr=011534c8 (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 013f891c lAllocID=337 dwSize=00000030,
> ReturnAddr=011534c8 (pid=00000570)
> Direct3D9: (ERROR) :Memory Address: 013fa634 lAllocID=338 dwSize=00001020,
> ReturnAddr=011534c8 (pid=00000570)
> Direct3D9: (ERROR) :Total Memory Unfreed From Current Process = 50504
> bytes
>
> How can I use the above information to know what is leaking? That's a lot
> of
> leaks!
>
> I really don't know what the problem is, because I am destroying ALL D3D
> resources and there should not be leaks.
>
>
>

Relevant Pages

  • Re: memory leaks when I resize window
    ... > use the break on alloc-id cpl feature and track down what D3D still thinks ... > it looks like you arent destroying all resources. ... >> cases I get leaks. ... someone else who is testing and various machines running WinXP ...
    (microsoft.public.win32.programmer.directx.graphics)
  • Re: [PATCH 11/19] perf record: Release resources at exit
    ... That's rather crappy of valgrind. ... can do a better job of finding leaks if there's a well defined "all resources ... Most apps free their stuff before they exit - i do it in all my own C apps. ...
    (Linux-Kernel)
  • Re: [PATCH 11/19] perf record: Release resources at exit
    ... That's certainly true but there's no valgrind crappiness here: ... can do a better job of finding leaks if there's a well defined "all resources ... Most apps free their stuff before they exit - i do it in all my own C apps. ...
    (Linux-Kernel)
  • Re: memory leak
    ... I would recomend the first step being to find out which "raw" ... The most watched resources are handles and address space. ... You can see that the most offending usage is from the heaps. ... will report all leaks in the debugger output window when ...
    (microsoft.public.win32.programmer.kernel)
  • Re: BeginInvoke without EndInvoke allowed?
    ... In principle there might be resource leaks which might be at least ... It's likely that finalizers will free up the resources, ... or the leaks accumulate until the process exits ... BeginInvoke is implemented in Windows Forms has been implemented in ...
    (microsoft.public.dotnet.framework)