-- [ Picked text/plain from multipart/alternative ] If you want a real quick and dirty method, I usually just open up Task Manager and watch the memory usage of the HL2 process.. You can observe the fluctuations as the game is being run. I was able to track down a memory leak with entities being spawned and not being deallocated properly using this method.
----- Original Message ----- From: "Jeremy" <[EMAIL PROTECTED]> To: <hlcoders@list.valvesoftware.com> Sent: Friday, January 11, 2008 11:04 AM Subject: Re: [hlcoders] CUtlVector<*>... Memory management? > -- > [ Picked text/plain from multipart/alternative ] > I haven't tried this with HL2, so I don't know how it would play with the > HL2 memory manager, but for memory leak detection, this is the best thing > since sliced bread for C++ > > http://www.codeproject.com/KB/applications/visualleakdetector.aspx > > J > > On Jan 11, 2008 10:58 AM, Jed <[EMAIL PROTECTED]> wrote: > >> Well its C++ so I always thought it was a case that you *have* to >> properly release any memory you allocate. I usually stick a debug >> header at the top of all my code files so if theres any memory leaks >> it'll tell me where they are when the program exits. >> >> - Jed >> >> On 11/01/2008, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > -- >> > [ Picked text/plain from multipart/alternative ] >> > That's what I'd like to know.. I'm not totally convinced that it's safe >> to >> > just leave stuff in the memory.. perhaps a member of Valve staff can >> > confirm? >> > >> > On Jan 11, 2008 6:28 PM, Minh <[EMAIL PROTECTED]> wrote: >> > >> > > -- >> > > [ Picked text/plain from multipart/alternative ] >> > > hmm.. I've gotten way with just calling >> > > RemoveAll() on my CUTLVectors. >> > > Then when I add new elements, I believe it just overtakes the >> > > existing >> > > memory addresses of these previous elements that were in the vector. >> Mind >> > > you, my utlvectors typically never grow to be more than 20 elements. >> > > >> > > When Half-Life2 shuts down, does all of the memory allocations that >> were >> > > created during the game get deallocated automatically, so other >> programs >> > > can >> > > use them? >> > > >> > > >> > > ----- Original Message ----- >> > > From: "Jamie Femia" <[EMAIL PROTECTED]> >> > > To: <hlcoders@list.valvesoftware.com> >> > > Sent: Friday, January 11, 2008 9:55 AM >> > > Subject: Re: [hlcoders] CUtlVector<*>... Memory management? >> > > >> > > >> > > > -- >> > > > [ Picked text/plain from multipart/alternative ] >> > > > Then why is it that when I try and delete the elements it crashes >> the >> > > > game? >> > > > lol... >> > > > >> > > > On Jan 11, 2008 5:37 PM, Tony omega Sergi <[EMAIL PROTECTED]> >> wrote: >> > > > >> > > >> -- >> > > >> [ Picked text/plain from multipart/alternative ] >> > > >> you have to delete what you add. purging just removes the >> > > >> elements. >> > > >> >> > > >> On Jan 11, 2008 11:35 AM, Jamie Femia <[EMAIL PROTECTED]> wrote: >> > > >> >> > > >> > -- >> > > >> > [ Picked text/plain from multipart/alternative ] >> > > >> > Am I right in assuming that if you have a vector of pointers, >> that >> > > >> > point >> > > >> > to >> > > >> > things you create with "new", you have to either call delete on >> each >> > > >> > element >> > > >> > or use PurgeAndDeleteElements()? Because that's what I've been >> using >> > > up >> > > >> > until recently, where it seems that trying to delete elements >> from a >> > > >> > pointer >> > > >> > vector on destruction of whatever they are members of just >> > > >> > causes >> the >> > > >> game >> > > >> > to crash with a memory error. Removing the calls to delete stop >> the >> > > >> crash, >> > > >> > but unless CUtlVector automatically cleans up your memory for >> you, >> > > >> > won't >> > > >> > this just create MASSIVE memory leaks? As far as I knew, >> CUtlVector >> > > >> > didn't >> > > >> > magically look after your memory for you... was I wrong? >> > > >> > >> > > >> > J >> > > >> > -- >> > > >> > >> > > >> > _______________________________________________ >> > > >> > To unsubscribe, edit your list preferences, or view the list >> > > archives, >> > > >> > please visit: >> > > >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> > >> > > >> > >> > > >> >> > > >> >> > > >> -- >> > > >> -omega >> > > >> -- >> > > >> >> > > >> _______________________________________________ >> > > >> To unsubscribe, edit your list preferences, or view the list >> archives, >> > > >> please visit: >> > > >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> >> > > >> >> > > > -- >> > > > >> > > > _______________________________________________ >> > > > To unsubscribe, edit your list preferences, or view the list >> archives, >> > > > please visit: >> > > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > > >> > > >> > > -- >> > > >> > > _______________________________________________ >> > > To unsubscribe, edit your list preferences, or view the list >> > > archives, >> > > please visit: >> > > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > > >> > > >> > -- >> > >> > _______________________________________________ >> > To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> > http://list.valvesoftware.com/mailman/listinfo/hlcoders >> > >> > >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > -- > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > -- _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
