ISO free tools to debug malloc/free bugs

Discussion in 'C Programming' started by kj, Dec 6, 2004.

  1. kj

    kj Guest

    For me, the hardest bugs to figure out have to do with malloc and/or
    free, because such a bug usually manifests itself as a seg fault
    happening at a place in the code that, AFAICT, can be totally
    unrelated to the code responsible for the bug.

    I know that there are commercial tools to help with such bugs, but
    I work at an academic lab on a shoestring, so we make do with open
    source tools unless it is absolutely unavoidable to spring for the
    non-free stuff.

    Are there any free tools to help tracking such bugs? FWIW, I use
    gcc-2.95.

    Thanks!

    kj

    --
    NOTE: In my address everything before the first period is backwards;
    and the last period, and everything after it, should be discarded.
    kj, Dec 6, 2004
    #1
    1. Advertising

  2. kj wrote:
    > For me, the hardest bugs to figure out have to do with malloc and/or
    > free, because such a bug usually manifests itself as a seg fault
    > happening at a place in the code that, AFAICT, can be totally
    > unrelated to the code responsible for the bug.
    >
    > I know that there are commercial tools to help with such bugs, but
    > I work at an academic lab on a shoestring, so we make do with open
    > source tools unless it is absolutely unavoidable to spring for the
    > non-free stuff.
    >
    > Are there any free tools to help tracking such bugs?


    Have a look at the excellent Valgrind. It's doubly free too.

    Daniel Vallstrom
    Daniel Vallstrom, Dec 6, 2004
    #2
    1. Advertising

  3. On Mon, 6 Dec 2004 14:21:51 +0000 (UTC), kj
    <> wrote:

    > For me, the hardest bugs to figure out have to do with malloc and/or
    > free, because such a bug usually manifests itself as a seg fault
    > happening at a place in the code that, AFAICT, can be totally
    > unrelated to the code responsible for the bug.
    >
    > I know that there are commercial tools to help with such bugs, but
    > I work at an academic lab on a shoestring, so we make do with open
    > source tools unless it is absolutely unavoidable to spring for the
    > non-free stuff.
    >
    > Are there any free tools to help tracking such bugs? FWIW, I use
    > gcc-2.95.


    Yes, dmalloc (http://dmalloc.com/). Some Linux systems have it already
    compiled as a package (Debian, for instance).

    The author does ask (but doesn't insist) that it you find it useful you
    make a donation (the actual software is released under a very permissive
    licence). I found it useful (incredibly so; after a week of trying to
    find a problem which caused free() to crash -- it was obviously
    something writing somewhere it shouldn't, but I couldn't see what -- I
    used dmalloc and it trapped the area being overwritten, I looked at the
    bad values in the guard area and it was obvious what did it)...

    Chris C
    Chris Croughton, Dec 6, 2004
    #3
  4. kj

    CBFalconer Guest

    kj wrote:
    >
    > For me, the hardest bugs to figure out have to do with malloc and/or
    > free, because such a bug usually manifests itself as a seg fault
    > happening at a place in the code that, AFAICT, can be totally
    > unrelated to the code responsible for the bug.
    >
    > I know that there are commercial tools to help with such bugs, but
    > I work at an academic lab on a shoestring, so we make do with open
    > source tools unless it is absolutely unavoidable to spring for the
    > non-free stuff.
    >
    > Are there any free tools to help tracking such bugs? FWIW, I use
    > gcc-2.95.


    If you use DJGPP (which you can under most editions of Windows or
    MsDos) you can use my nmalloc package (which was written for DJGPP,
    but has not yet been incorporated). It includes a debugging
    package, and info documentation entries for it all. You can find
    it at:

    <http://cbfalconer.home.att.net/download/nmalloc.zip>

    Ignore the memalign garbage in the package, that is incomplete. It
    might function with other systems than DJGPP, but that is a
    separate matter, and no guarantees.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Dec 6, 2004
    #4
  5. kj wrote:
    > For me, the hardest bugs to figure out have to do with malloc and/or
    > free, because such a bug usually manifests itself as a seg fault
    > happening at a place in the code that, AFAICT, can be totally
    > unrelated to the code responsible for the bug.
    >


    You can use a garbage collector like Boehm. It also does malloc debugging.

    http://www.hpl.hp.com/personal/Hans_Boehm/gc/

    Also, you might be interested in my DeveloperWorks article on memory
    management:

    http://www-106.ibm.com/developerworks/linux/library/l-memory/

    It has a lot of interesting ideas and good resources.

    Jon
    ----
    Learn to program using Linux assembly language
    http://www.cafeshops.com/bartlettpublish.8640017
    Jonathan Bartlett, Dec 6, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John
    Replies:
    13
    Views:
    689
  2. ravi
    Replies:
    0
    Views:
    441
  3. Peter
    Replies:
    34
    Views:
    1,923
    Richard Tobin
    Oct 22, 2004
  4. Josef 'Jupp' Schugt

    Still use 'ruby-bugs' for Ruby bugs?

    Josef 'Jupp' Schugt, Nov 4, 2004, in forum: Ruby
    Replies:
    2
    Views:
    156
    Tom Copeland
    Nov 4, 2004
  5. bill

    ISO Perl reported bugs database

    bill, Apr 19, 2005, in forum: Perl Misc
    Replies:
    4
    Views:
    104
    Tad McClellan
    Apr 20, 2005
Loading...

Share This Page