Re: malloc in inferior

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote:
> I have finally figured out that the reason gdb
> keeps crashing my embedded system is that it
> tries to call malloc at the drop of a hat.
> 
> There are various contexts in our code where
> performing a memory allocation is disallowed.
> This is enforced by our allocation primitives.
> 
> Our system does not uses malloc.  The malloc
> that is part of the c-runtime calls through a
> null function pointer, triggering a machine
> reset.  So something as simple as
> 
> (gdb) print "foo"
> 
> causes a crash.
> 
> Why can gdb not allocate values within its own
> address space?

Because it's not useful to do so.  Sure, trivial examples like
print "foo" could be done this way; and it would be nice to do that. 
But to do anything more complicated requires materializing them in the
inferior.  Some optimization is missing but you can't get away from the
problem that way.

> I understand that to support calling functions
> in the inferior gdb may have to materialize
> values there.  But these should be pushed into
> the inferior once it is clear that they need to
> exist there.
> 
> And how can gdb possibly debug a multi-threaded
> application with a thread-safe malloc?

This wasn't considered in the current design, true.  I'm open to
suggestions.

> One possibility would be to add malloc and free
> messages to the remote protocol.  Then a stub
> could allocation memory in the proper address
> space without interacting with the inferior's
> environment.
> 
> Another would be to have a stub provide a block
> of memory.  A query would determine the address
> and size of this block.  Then gdb could manage
> the memory entirely on its own.

For some stubs these would be useful; for the stubs I deal with, which
sit in user space on normal OS's, rather less so.  The stub would end
up calling malloc anyway.

Personally, I'm of the opinion that we should solve this problem by
changing the definitions: mark strings as ephemeral and let the user
call malloc or strdup directly if they want something to last.  Or make
it a set option.  I'm not sure how popular that idea would be; anyone
else have a comment?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer