l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2003 Nov 18 19:16

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] Assistance With C Program
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] Assistance With C Program

hi dan,

On Tue 18 Nov 03,  4:40 PM, Daniel Hurt <dwhurt@ucdavis.edu> said:
> Specifically:  Finding possible memory leaks and when it is appropriate to 
> use the free() functions. Next, I am not too terribly sure on how to use a 
> debugger to track down the leak.  Finally, just discussing programming 
> style with someone who knows C to look at it and critique the code.  The 
> code itself works, it just takes an exceedingly long time and every so 
> often I am running into problems with the size of the program.  I do not 
> need help with the physics behind what is going on because the code 
> actually generates good results. I am just trying to analyze larger 
> systems that should be well within the limits and encountering problems.
if i can guess at what your research is, you don't need to use dynamic
memory for your spin lattice if you use c99.  you can declare arrays
with non-constants, so you can do something like this:

./montecarlo --latticesize=50

and you don't need to allocate the array dynamically.

but to answer your question, it's always appropriate to use free()
whenever you use malloc() and friends (except for dynamic memory
allocated from the stack, like alloca()).  if you don't, the memory is
unavailable for the duration of your application, but will be returned
when your program exits.  if you're doing monte carlo on small lattices,
a memory leak is really not a big deal since you only allocate the array
once.  it's just unaesthetic.

to answer your question about how to find memory leaks: there's lots and
lots and lots of ways.  some easy, and some hard.  look at

   info libc

and do a search on MALLOC_CHECK.  you'll be taken to a node that has a
few ways to catch dynamic memory problems.  the simplest method is the
MALLOC_CHECK_ method itself (note the terminating underscore).

basically, you'll want to set an environment variable named
MALLOC_CHECK_ to a 0 (to ignore problems), a 1 (to warn about problems)
or a 2 (to dump core when a problem is encountered) or a 3 (to both warn
and dump core when a problem is encountered).

note that "3" is undocumented.   you can invoke it like so:

   $ MALLOC_CHECK_=3 ./myprogram

i can give you further guidance if you need it.

there are meny other ways.  see "man efence" for example.  electric
fence is another tool to debug dyanmic memory problems.  each tool has
its strengths and weaknesses.  

for instance, MALLOC_CHECK_ doesn't work with the concept of
"boundaries" while electric fence does.  this means that efence can
catch certain problems that MALLOC_CHECK_ can't.  for instance, i
believe pure memory leaks will not be detected by MALLOC_CHECK_, while
things like double frees and writing to freed memory will.


GPG Instructions: http://www.dirac.org/linux/gpg
GPG Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D
vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.