malloc() debugging

malloc() debugging

[Fredrik Tolf]

I'm trying to make a multithreaded program, but I've run into some problems. It appears as I am somehow modifying malloc's data structures (those in front of the allocated chunk, I'm using glibc), and thus the program crashes sometimes when the malloc related are called, most usually in free. The strangest thing, as I see it, is that (at least last time it crashed from this), the first word of that structure (prev_size) wasn't modified, but only the second word (size). The most probable reason I can see for an error of this kind would otherwise be a buffer overflow from the chunk before.
Anyhow, the reason that I'm mailing to this list is that I'm wondering if it's possible to configure gdb to break whenever one of these structures is modified by an instruction outside the address range of the malloc related functions. If noone knows how this would be done, could you notify of any other good tool to find these conditions? Can valgrind detect it?

Fredrik Tolf

Re: malloc() debugging

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 09:07:46PM +0100, Fredrik Tolf wrote:
> I'm trying to make a multithreaded program, but I've run into some
> problems. It appears as I am somehow modifying malloc's data
> structures (those in front of the allocated chunk, I'm using glibc),
> and thus the program crashes sometimes when the malloc related are
> called, most usually in free. The strangest thing, as I see it, is
> that (at least last time it crashed from this), the first word of
> that structure (prev_size) wasn't modified, but only the second word
> (size). The most probable reason I can see for an error of this kind
> would otherwise be a buffer overflow from the chunk before. Anyhow,
> the reason that I'm mailing to this list is that I'm wondering if
> it's possible to configure gdb to break whenever one of these
> structures is modified by an instruction outside the address range of
> the malloc related functions. If noone knows how this would be done,
> could you notify of any other good tool to find these conditions? Can
> valgrind detect it?

Nope, GDB can't do this.  You may want to try either Electric Fence or
dmalloc; dmalloc does work in multithreaded programs (although it needs
a little coaxing).

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: malloc() debugging

[Fredrik Tolf]

----- Original Message ----- 
From: "Daniel Jacobowitz" <drow@mvista.com>
To: "Fredrik Tolf" <fredrik@dolda2000.cjb.net>
Cc: <gdb@sources.redhat.com>
Sent: Wednesday, October 30, 2002 9:11 PM
Subject: Re: malloc() debugging


> On Wed, Oct 30, 2002 at 09:07:46PM +0100, Fredrik Tolf wrote:
> > I'm trying to make a multithreaded program, but I've run into some
> > problems. It appears as I am somehow modifying malloc's data
> > structures (those in front of the allocated chunk, I'm using glibc),
> > and thus the program crashes sometimes when the malloc related are
> > called, most usually in free. The strangest thing, as I see it, is
> > that (at least last time it crashed from this), the first word of
> > that structure (prev_size) wasn't modified, but only the second word
> > (size). The most probable reason I can see for an error of this kind
> > would otherwise be a buffer overflow from the chunk before. Anyhow,
> > the reason that I'm mailing to this list is that I'm wondering if
> > it's possible to configure gdb to break whenever one of these
> > structures is modified by an instruction outside the address range of
> > the malloc related functions. If noone knows how this would be done,
> > could you notify of any other good tool to find these conditions? Can
> > valgrind detect it?
> 
> Nope, GDB can't do this.  You may want to try either Electric Fence or
> dmalloc; dmalloc does work in multithreaded programs (although it needs
> a little coaxing).
> 
Shouldn't gdb be enabled to do this in that case?
Speaking of which, can't gdb create watchpoints to these structuress every time malloc is called with conditions of $pc outside the malloc functions and delete them when free is called? I'm not very experienced with gdb, but shouldn't it be possible, or, if not, be made possible?
> -- 
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
> 

Re: malloc() debugging

[Daniel Jacobowitz]

On Wed, Oct 30, 2002 at 09:17:17PM +0100, Fredrik Tolf wrote:
> ----- Original Message ----- 
> From: "Daniel Jacobowitz" <drow@mvista.com>
> To: "Fredrik Tolf" <fredrik@dolda2000.cjb.net>
> Cc: <gdb@sources.redhat.com>
> Sent: Wednesday, October 30, 2002 9:11 PM
> Subject: Re: malloc() debugging
> 
> 
> > On Wed, Oct 30, 2002 at 09:07:46PM +0100, Fredrik Tolf wrote:
> > > I'm trying to make a multithreaded program, but I've run into some
> > > problems. It appears as I am somehow modifying malloc's data
> > > structures (those in front of the allocated chunk, I'm using glibc),
> > > and thus the program crashes sometimes when the malloc related are
> > > called, most usually in free. The strangest thing, as I see it, is
> > > that (at least last time it crashed from this), the first word of
> > > that structure (prev_size) wasn't modified, but only the second word
> > > (size). The most probable reason I can see for an error of this kind
> > > would otherwise be a buffer overflow from the chunk before. Anyhow,
> > > the reason that I'm mailing to this list is that I'm wondering if
> > > it's possible to configure gdb to break whenever one of these
> > > structures is modified by an instruction outside the address range of
> > > the malloc related functions. If noone knows how this would be done,
> > > could you notify of any other good tool to find these conditions? Can
> > > valgrind detect it?
> > 
> > Nope, GDB can't do this.  You may want to try either Electric Fence or
> > dmalloc; dmalloc does work in multithreaded programs (although it needs
> > a little coaxing).
> > 
> Shouldn't gdb be enabled to do this in that case? Speaking of which,
> can't gdb create watchpoints to these structuress every time malloc
> is called with conditions of $pc outside the malloc functions and
> delete them when free is called? I'm not very experienced with gdb,
> but shouldn't it be possible, or, if not, be made possible?

No.  Every real system (non-simulator) with watchpoints at all has a
finite number of them.  Usually no more than a handful.

You can use GDB in combination with dmalloc; dmalloc triggers an
exception when you corrupt the data structures and GDB tells you where
you are.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: malloc() debugging

[Eli Zaretskii]

On Wed, 30 Oct 2002, Daniel Jacobowitz wrote:

> No.  Every real system (non-simulator) with watchpoints at all has a
> finite number of them.  Usually no more than a handful.

However, some systems have lots of resources to put watchpoints.  An 
example is MIPS/Irix.

I think the real problem with this suggestion is elsewehere; see my other 
message in this thread.

Re: malloc() debugging

[Eli Zaretskii]

On Wed, 30 Oct 2002, Fredrik Tolf wrote:

> Shouldn't gdb be enabled to do this in that case?

You cannot do that in a general manner; see below.

> Speaking of which, can't gdb create watchpoints to these structuress 
> every time malloc is called with conditions of $pc outside the malloc 
> functions and delete them when free is called?

That might work (barring the problem with limited watchpoint resources), 
but the showstopper is that you need an intimate knowledge about the C 
library's implementation of malloc, and you need to make sure the program 
was linked against a version of the library where debug info wasn't 
stripped.