| Author |
Message |
|
Andy Fel
#1 / 12
|
 debugging tips: malloc() Hi Folks- I wonder if you could provide some debugging tips. I'm pretty sure I am (excerpted from FAQ 7.19): writing more to a malloc'ed region than it was allocated to hold
because the program runs fine under DEC cc, but under gcc on linux I get a
segmentation fault when calling malloc. I am sure the pointer is
unassigned, as it is local to the subroutine.
OK, so somewhere before this, I'm writing too far, but how do I find it? In
this program I am allocating, freeing, resizing all over the place. Going
line by line would take a week. Any good techniques out there I should know
about? ..flags I should set on gcc? I have gdb, but am a novice.
Thanks much!
Andy
-------------------------------------------------------------------
Dept. of Pure and Applied Mathematics| |
Washington State University | http://www.*-*-*.com/ ~felta/ |
-------------------------------------------------------------------
Be the person your dog thinks you are.
--
|
| Tue, 05 Feb 2002 03:00:00 GMT |
|
 |
|
Tommy Knowlto
#2 / 12
|
debugging tips: malloc() There are a number of debug-malloc libraries out there, many come from OS vendors, others are freely available from third parties, and still others cost $$ from third parties. I only know of two in particular, one is the watchmalloc library that comes with later versions of Solaris (2.6 & up), the other is a product from ParaSoft, and they have versions for several OS's. The product is called Insure, and it actually is the best debugging tool I've ever used for such a purpose. But since it was while I was undergraduate at University, and I haven't used it since, I don't know how to obtain it. ParaSoft homepage is at http://www.parasoft.com, they appear to have some info in it there. I don't know where, although I am assuming there might be a gnu malloc library
implementation that may help you debug.
Good luck.
--Tommy.
Quote:
> Hi Folks- > I wonder if you could provide some debugging tips. I'm pretty sure I am > (excerpted from FAQ 7.19): > writing more to a malloc'ed region than it was allocated to hold
> because the program runs fine under DEC cc, but under gcc on linux I get a
> segmentation fault when calling malloc. I am sure the pointer is
> unassigned, as it is local to the subroutine.
> OK, so somewhere before this, I'm writing too far, but how do I find it? In
> this program I am allocating, freeing, resizing all over the place. Going
> line by line would take a week. Any good techniques out there I should know
> about? ..flags I should set on gcc? I have gdb, but am a novice.
> Thanks much!
> Andy
> -------------------------------------------------------------------
> Dept. of Pure and Applied Mathematics| |
> Washington State University | http://www.wsu.edu/~felta/ |
> -------------------------------------------------------------------
> Be the person your dog thinks you are.
> --
--
|
| Wed, 06 Feb 2002 03:00:00 GMT |
|
|
|
Peter Burk
#3 / 12
|
debugging tips: malloc() Quote:
> Hi Folks-
> I wonder if you could provide some debugging tips. I'm pretty sure I am
> (excerpted from FAQ 7.19):
> writing more to a malloc'ed region than it was allocated to hold
> because the program runs fine under DEC cc, but under gcc on linux I get a
> segmentation fault when calling malloc. I am sure the pointer is
> unassigned, as it is local to the subroutine.
> OK, so somewhere before this, I'm writing too far, but how do I find it? In
> this program I am allocating, freeing, resizing all over the place. Going
> line by line would take a week. Any good techniques out there I should know
> about? ..flags I should set on gcc? I have gdb, but am a novice.
> Thanks much!
> Andy
There are various tools that can help you find this kind of bug. I've written some simple wrappers for malloc and free which allocate
a bit of extra memory on each malloc, and fill the 'padding' with
known bytes. On every malloc or free I walk all of the memory blocks
and test to make sure that the padding hasn't been altered. This
lets you at least determine which memory block is being corrupted,
and helps you guess when it happened.
(The code's at work, so I can't post it, sorry! But it's pretty
simple stuff)
/peter
--
|
| Wed, 06 Feb 2002 03:00:00 GMT |
|
|
|
Ben Pfaf
#4 / 12
|
debugging tips: malloc()
OK, so somewhere before this, I'm writing too far, but how do I find it? In
this program I am allocating, freeing, resizing all over the place. Going
line by line would take a week. Any good techniques out there I should know
about? ..flags I should set on gcc? I have gdb, but am a novice.
There are many system-specific debugging tools available. For Linux,
look for Electric Fence and Checker; for other systems, Bounds Checker
and Purify may be useful.
There are also some fairly generic systems available, but they are
less useful and less certain to find your problem.
--
"It takes a certain amount of shamelessness
to be a monomaniac billionaire dwarf."
--Jon Katz <URL:http://slashdot.org/articles/99/03/17/1634238.shtml>
--
|
| Wed, 06 Feb 2002 03:00:00 GMT |
|
|
|
Paul Lutu
#5 / 12
|
debugging tips: malloc() << Going line by line would take a week. >> And writing it correctly in the first place would have taken a day. This is
how we learn to program. It's why seasoned programmers are so nit-picky
about details and syntax.
Now there is no alternative. You must debug it by thinking of everything
that might be wrong. There is no shortcut.
Good luck!
--
Paul Lutus
www.arachnoid.com
<snip>
--
|
| Wed, 06 Feb 2002 03:00:00 GMT |
|
|
|
Peter Seeba
#6 / 12
|
debugging tips: malloc()
Quote: >because the program runs fine under DEC cc, but under gcc on linux I get a
>segmentation fault when calling malloc. I am sure the pointer is
>unassigned, as it is local to the subroutine.
>OK, so somewhere before this, I'm writing too far, but how do I find it? In
>this program I am allocating, freeing, resizing all over the place. Going
>line by line would take a week. Any good techniques out there I should know
>about? ..flags I should set on gcc? I have gdb, but am a novice.
As noted, when you get a segfault from malloc, an earlier free was probably wrong. My solution to problems like this was a debug malloc library which carefully
logs everything that happens, coupled with a perl script which analyzes
the output. I only ever found one memory problem it couldn't track for me:
I had a "temporary" memory leak; basically, I had lots of things I had
allocated and attached to a list, but I didn't realize they were on the list.
When the list went away, all my memory came back. I didn't mean to be doing
this, but the malloc library couldn't find them, because they were, after
all, all getting freed correctly.
I believe this is in my halfway-portable set of unixy utilities and libraries,
but I don't think I ever made it separable. Maybe I should... Anyone
interested? It's crufty code, I wrote it probably four or five years ago.
Ugh. It's cruftier than I remember; I'll clean it up a little.
-s
--
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
--
|
| Wed, 06 Feb 2002 03:00:00 GMT |
|
|
|
Peter Seeba
#7 / 12
|
debugging tips: malloc()
Quote: >I've written some simple wrappers for malloc and free which allocate
>a bit of extra memory on each malloc, and fill the 'padding' with
>known bytes. On every malloc or free I walk all of the memory blocks
>and test to make sure that the padding hasn't been altered. This
>lets you at least determine which memory block is being corrupted,
>and helps you guess when it happened.
Oh, hey, that's clever. Mine just checks them when you free or realloc them, not the rest of the time. -s
--
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Will work for interesting hardware. http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
--
|
| Wed, 06 Feb 2002 03:00:00 GMT |
|
|
|
Peter Burk
#8 / 12
|
debugging tips: malloc() Quote:
> >I've written some simple wrappers for malloc and free which allocate
> >a bit of extra memory on each malloc, and fill the 'padding' with
> >known bytes. On every malloc or free I walk all of the memory blocks
> >and test to make sure that the padding hasn't been altered. This
> >lets you at least determine which memory block is being corrupted,
> >and helps you guess when it happened.
> Oh, hey, that's clever. Mine just checks them when you free or realloc
> them, not the rest of the time.
Thanks! Its pretty easy to do, too. Since you're allocating extra memory anyways, I just allocate two more pointers at the beginning of the block, and use them to maintain a doubly linked list of all the memory allocated. e.g.
void* previousBlock;
void* nextBlock;
char headPadding[PADSIZE];
.. . . real data
char tailPadding[PADSIZE];
Of course this can cause problems if the pointers
get corrupted, but thats usually pretty easy to debug.
It can also really slow things down, but its worth it
to save a few hours of debugging time.
/peter (seeing if he can get this thread cross-posted to a.u.e, too :)
--
|
| Thu, 07 Feb 2002 03:00:00 GMT |
|
|
|
Andrew Isaacs
#9 / 12
|
debugging tips: malloc()
Quote: >Hi Folks- >I wonder if you could provide some debugging tips. I'm pretty sure I am >(excerpted from FAQ 7.19): >writing more to a malloc'ed region than it was allocated to hold
>because the program runs fine under DEC cc, but under gcc on linux I get a
>segmentation fault when calling malloc. I am sure the pointer is
>unassigned, as it is local to the subroutine.
>OK, so somewhere before this, I'm writing too far, but how do I find it? In
>this program I am allocating, freeing, resizing all over the place. Going
>line by line would take a week. Any good techniques out there I should know
>about? ..flags I should set on gcc? I have gdb, but am a novice.
Fetch Electric Fence from http://perens.com/FreeSoftware/ and read the included documentation. mprotect() will set you free. :) -andy
--
|
| Fri, 08 Feb 2002 03:00:00 GMT |
|
|
|
Friedrich Dominicu
#10 / 12
|
debugging tips: malloc() Quote: > OK, so somewhere before this, I'm writing too far, but how do I find it? In
> this program I am allocating, freeing, resizing all over the place. Going
> line by line would take a week. Any good techniques out there I should know
> about? ..flags I should set on gcc? I have gdb, but am a novice.
Other have pointed out using a kind of debug mallocs. But nobody suggested dmalloc So maybe you should use this package and/or Electric Fence to help you tracking down the fault. Hope this helps a bit.
Friedrich
--
|
| Sun, 10 Feb 2002 03:00:00 GMT |
|
|
|
Andy Fel
#11 / 12
|
debugging tips: malloc() Thank you all very much for the helpful, positive responses. I downloaded Electric Fence, and once I got it running, I found the problem in 5 minutes. I really must say, it's a great tool, and if I can get it to run, anyone can. I'm very impressed with everyone on this list. You could have shook your
finger and said, "Be more careful with your memory." Of course, I have
learned that lesson. Instead you gave constructive help. I appreciate it.
Andy
-------------------------------------------------------------------
Dept. of Pure and Applied Mathematics| |
Washington State University | http://www.wsu.edu/~felta/ |
-------------------------------------------------------------------
Be the person your dog thinks you are.
--
|
| Sun, 10 Feb 2002 03:00:00 GMT |
|
| |
|
