Re: [hlcoders] Detecting Memory Leaks

2009-07-06 Thread Garry Newman
I just derive all my objects from a class that spazzes out on exit if
it isn't unallocated. But that's probably the kind of thing that you
have to do from the start, so you know that whatever you changed last
caused a leak - rather than later.

The built in _CRTDBG_MAP_ALLOC stuff has worked for me in the past,
when I had no idea where the hell the leak was coming from..

garry

On Mon, Jul 6, 2009 at 2:22 AM, Minh minh...@telus.net wrote:

 Sweat.. if Alfred and God created Alfred Reynolds suggested it, it
 must be useful. I had trouble linking glowcode to my actual code, so it
 kept spitting out some incoherent gibberish.
 Someone suggested that I code better and not put leaks in my code in the
 first place.. This certain somewhere is sitting at the bottom of the
 ocean with concrete blocks attached to this feet.

 Justin Krenz wrote:
  How does Glowcode interface with the DLLs?
 
  Alfred suggested I use Memory Validator, but it requires your DLLs to
  be compiled with Run Time Library: Multi-threaded DLL.  The SDK dlls
  need to be compiled with Run Time Library: Multi-threaded otherwise
  there are linker errors in some of the static libraries which don't
  have their source included in the SDK.  I'm curious how Glowcode works
  where Memory Validator fails.
 
  I followed a tutorial once on manually adding memory tracking, and it
  worked all right.  It turned out very slow, but it works if you have
  the patience: 
  http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
  /tier0/memoverride.cpp is where all of the new and delete operators
  are already overridden where you add the tracking code.  When I used
  it, all it did though was confirm my suspicions that my memory leak
  wasn't happening in my code.
 
  On Sun, Jul 5, 2009 at 7:16 PM, Minhminh...@telus.net wrote:
 
  I was wondering what tools you guys use to track memory leaks. I've
  tried using a program called Glowcode and it's not terribly helpful as
  it doesn't exactly pin point the offending areas of code. I looked at a
  program called DevPartner which my friend really recommends but it costs
  $2000.. and when I try signing up for a trial version, the idiots never
  get back to me.
 
  ___
  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



Re: [hlcoders] Detecting Memory Leaks

2009-07-06 Thread Minh
hmm.. yea, it's prolly too late for me to do that but thanks for the 
suggestion. I think I'm just gonna figure out how to use Memory Validator.

Garry Newman wrote:
 I just derive all my objects from a class that spazzes out on exit if
 it isn't unallocated. But that's probably the kind of thing that you
 have to do from the start, so you know that whatever you changed last
 caused a leak - rather than later.

 The built in _CRTDBG_MAP_ALLOC stuff has worked for me in the past,
 when I had no idea where the hell the leak was coming from..

 garry

 On Mon, Jul 6, 2009 at 2:22 AM, Minh minh...@telus.net wrote:
   
 Sweat.. if Alfred and God created Alfred Reynolds suggested it, it
 must be useful. I had trouble linking glowcode to my actual code, so it
 kept spitting out some incoherent gibberish.
 Someone suggested that I code better and not put leaks in my code in the
 first place.. This certain somewhere is sitting at the bottom of the
 ocean with concrete blocks attached to this feet.

 Justin Krenz wrote:
 
 How does Glowcode interface with the DLLs?

 Alfred suggested I use Memory Validator, but it requires your DLLs to
 be compiled with Run Time Library: Multi-threaded DLL.  The SDK dlls
 need to be compiled with Run Time Library: Multi-threaded otherwise
 there are linker errors in some of the static libraries which don't
 have their source included in the SDK.  I'm curious how Glowcode works
 where Memory Validator fails.

 I followed a tutorial once on manually adding memory tracking, and it
 worked all right.  It turned out very slow, but it works if you have
 the patience: 
 http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
 /tier0/memoverride.cpp is where all of the new and delete operators
 are already overridden where you add the tracking code.  When I used
 it, all it did though was confirm my suspicions that my memory leak
 wasn't happening in my code.

 On Sun, Jul 5, 2009 at 7:16 PM, Minhminh...@telus.net wrote:

   
 I was wondering what tools you guys use to track memory leaks. I've
 tried using a program called Glowcode and it's not terribly helpful as
 it doesn't exactly pin point the offending areas of code. I looked at a
 program called DevPartner which my friend really recommends but it costs
 $2000.. and when I try signing up for a trial version, the idiots never
 get back to me.

 ___
 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



Re: [hlcoders] Detecting Memory Leaks

2009-07-06 Thread David Kraeutmann
Change CBaseEntity to subclass from that class?

On 7/6/09, Minh minh...@telus.net wrote:
 hmm.. yea, it's prolly too late for me to do that but thanks for the
 suggestion. I think I'm just gonna figure out how to use Memory Validator.

 Garry Newman wrote:
 I just derive all my objects from a class that spazzes out on exit if
 it isn't unallocated. But that's probably the kind of thing that you
 have to do from the start, so you know that whatever you changed last
 caused a leak - rather than later.

 The built in _CRTDBG_MAP_ALLOC stuff has worked for me in the past,
 when I had no idea where the hell the leak was coming from..

 garry

 On Mon, Jul 6, 2009 at 2:22 AM, Minh minh...@telus.net wrote:

 Sweat.. if Alfred and God created Alfred Reynolds suggested it, it
 must be useful. I had trouble linking glowcode to my actual code, so it
 kept spitting out some incoherent gibberish.
 Someone suggested that I code better and not put leaks in my code in the
 first place.. This certain somewhere is sitting at the bottom of the
 ocean with concrete blocks attached to this feet.

 Justin Krenz wrote:

 How does Glowcode interface with the DLLs?

 Alfred suggested I use Memory Validator, but it requires your DLLs to
 be compiled with Run Time Library: Multi-threaded DLL.  The SDK dlls
 need to be compiled with Run Time Library: Multi-threaded otherwise
 there are linker errors in some of the static libraries which don't
 have their source included in the SDK.  I'm curious how Glowcode works
 where Memory Validator fails.

 I followed a tutorial once on manually adding memory tracking, and it
 worked all right.  It turned out very slow, but it works if you have
 the patience:
 http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
 /tier0/memoverride.cpp is where all of the new and delete operators
 are already overridden where you add the tracking code.  When I used
 it, all it did though was confirm my suspicions that my memory leak
 wasn't happening in my code.

 On Sun, Jul 5, 2009 at 7:16 PM, Minhminh...@telus.net wrote:


 I was wondering what tools you guys use to track memory leaks. I've
 tried using a program called Glowcode and it's not terribly helpful as
 it doesn't exactly pin point the offending areas of code. I looked at
 a
 program called DevPartner which my friend really recommends but it
 costs
 $2000.. and when I try signing up for a trial version, the idiots
 never
 get back to me.

 ___
 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



-- 
Sent from my mobile device

___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders



Re: [hlcoders] Detecting Memory Leaks

2009-07-05 Thread Justin Krenz
How does Glowcode interface with the DLLs?

Alfred suggested I use Memory Validator, but it requires your DLLs to
be compiled with Run Time Library: Multi-threaded DLL.  The SDK dlls
need to be compiled with Run Time Library: Multi-threaded otherwise
there are linker errors in some of the static libraries which don't
have their source included in the SDK.  I'm curious how Glowcode works
where Memory Validator fails.

I followed a tutorial once on manually adding memory tracking, and it
worked all right.  It turned out very slow, but it works if you have
the patience: http://www.flipcode.com/archives/How_To_Find_Memory_Leaks.shtml
/tier0/memoverride.cpp is where all of the new and delete operators
are already overridden where you add the tracking code.  When I used
it, all it did though was confirm my suspicions that my memory leak
wasn't happening in my code.

On Sun, Jul 5, 2009 at 7:16 PM, Minhminh...@telus.net wrote:
 I was wondering what tools you guys use to track memory leaks. I've
 tried using a program called Glowcode and it's not terribly helpful as
 it doesn't exactly pin point the offending areas of code. I looked at a
 program called DevPartner which my friend really recommends but it costs
 $2000.. and when I try signing up for a trial version, the idiots never
 get back to me.

 ___
 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



Re: [hlcoders] Detecting Memory Leaks

2009-07-05 Thread Jorge Rodriguez
I know of a memory manager by Paul Nettle I think that is pretty decent, but
I don't think it will cooperate with the Source Engine. There's also
valgrind, but that will only help you for the Linux binary. Bounds Checker
of course is an option, and as previously mentioned memoverride is where the
action is.

-- 
Jorge Vino Rodriguez
___
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders