malloc in inferior

malloc in inferior

[John S. Yates, Jr.]

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?

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?

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.

/john
--
John S. Yates, Jr.   508 665-6897 (voice)
Netezza Inc          508 665-6811 (fax)
200 Crossing Blvd.   Framingham, MA 01701

Re: malloc in inferior

[Daniel Jacobowitz]

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

Re: malloc in inferior

[John S. Yates, Jr.]

From: "Daniel Jacobowitz" <drow@mvista.com>
To: "John S. Yates, Jr." <jyates@netezza.com>
Cc: "gdb" <gdb@sources.redhat.com>
Sent: Thursday, May 29, 2003 11:27 AM
Subject: Re: malloc in inferior


> On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote:

[..SNIP..]

> > 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.

Is there anything short of calling a function in the
target that requires materialization in the inferior?
I can perform an enormous amount of debugging without
ever thinking about trying to call a function.


> > 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.

I think this suggestion got missed.  Instead of today's
immediate materialization in the inferior against the
possibility that the value might be required there in
the future why not use a lazy approach?  Before calling
an inferior function push down any accessible objects.
 
> > 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.

This may be the case for the first suggestion.  The
second was that gdb have access to a chunk of memory
that it manages itself.  That is the allocation and
freeing would operator on structures in gdb's address
space, only the actual memory would exist in the
inferior.  In a remote stub the block of memory might
simply be a large static array.

> 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?

The problem is more general than just strings.

/john

Re: malloc in inferior

[Daniel Jacobowitz]

On Thu, May 29, 2003 at 12:00:44PM -0400, John S. Yates, Jr. wrote:
> 
> From: "Daniel Jacobowitz" <drow@mvista.com>
> To: "John S. Yates, Jr." <jyates@netezza.com>
> Cc: "gdb" <gdb@sources.redhat.com>
> Sent: Thursday, May 29, 2003 11:27 AM
> Subject: Re: malloc in inferior
> 
> 
> > On Thu, May 29, 2003 at 09:51:15AM -0400, John S. Yates, Jr. wrote:
> 
> [..SNIP..]
> 
> > > 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.
> 
> Is there anything short of calling a function in the
> target that requires materialization in the inferior?
> I can perform an enormous amount of debugging without
> ever thinking about trying to call a function.

What can you usefully do with strings that doesn't communicate them to
the inferior?

For instance, assigning "set x = "abc"" must materialize it in the
inferior.

> > > 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.
> 
> I think this suggestion got missed.  Instead of today's
> immediate materialization in the inferior against the
> possibility that the value might be required there in
> the future why not use a lazy approach?  Before calling
> an inferior function push down any accessible objects.

I didn't miss it; see above.  It would have to happen every time the
inferior is _resumed_, too.

> > > 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.
> 
> This may be the case for the first suggestion.  The
> second was that gdb have access to a chunk of memory
> that it manages itself.  That is the allocation and
> freeing would operator on structures in gdb's address
> space, only the actual memory would exist in the
> inferior.  In a remote stub the block of memory might
> simply be a large static array.

Which would, in a protected memory system, have to be allocated in the
child anyway.  And you can't call malloc() before program
initialization necessarily.

> > 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?
> 
> The problem is more general than just strings.

Care to give another example of when GDB calls malloc?  Strings are far
and away the most common.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: malloc in inferior

[John S. Yates, Jr.]

From: "Daniel Jacobowitz" <drow@mvista.com>

[..SNIP..]

> > Is there anything short of calling a function in the
> > target that requires materialization in the inferior?
> > I can perform an enormous amount of debugging without
> > ever thinking about trying to call a function.
> 
> What can you usefully do with strings that doesn't communicate them to
> the inferior?
> 
> For instance, assigning "set x = "abc"" must materialize it in the
> inferior.

Well as it so happens I was writing a "user-defined
command" to walk from a task control block out 3
levels.  My command had to guard against instances
when outer levels of the structure did not exist.
In such cases it tried to provide a clear diagnostic.
The task control block contains an char tcb_name[8]
member.  Since at times there might not even be a
task running there might not be a valid task name.
Thus I had

$task_name = ""      // even this calls malloc
$tcb = 0
$ptr1 = 0
$ptr2 = 0
if TCD_Current_Task
    $tcb = TCD_Current_Task
    $task_name = TCD_Current_Task->tcb_name
else
    printf "no current task\n"
end

if $tcb
    $ptr1 = $tcb->tcb_ptr1
    if ! $ptr1
        print "task %s: tcb_ptr1 is null\n",$task_name
    end
end

if $ptr1
    $ptr2 = $ptr1->xxx_ptr2
    if ! $ptr2
        print "task %s: xxx_ptr2 is null\n",$task_name
    end
end

...

[..SNIP..]

> > I think this suggestion got missed.  Instead of today's
> > immediate materialization in the inferior against the
> > possibility that the value might be required there in
> > the future why not use a lazy approach?  Before calling
> > an inferior function push down any accessible objects.
> 
> I didn't miss it; see above.  It would have to happen every time the
> inferior is _resumed_, too.

No.  An object is only accessible in the inferior
if its address has been 

  1) manifested (always true for string literals)
  2) supplied to the inferior via assignment (to
     inferior storage) or as an argument to an
     inferior function call

[..SNIP..]

> > This may be the case for the first suggestion.  The
> > second was that gdb have access to a chunk of memory
> > that it manages itself.  That is the allocation and
> > freeing would operator on structures in gdb's address
> > space, only the actual memory would exist in the
> > inferior.  In a remote stub the block of memory might
> > simply be a large static array.
> 
> Which would, in a protected memory system, have to be allocated in the
> child anyway.  And you can't call malloc() before program
> initialization necessarily.

Under the lazy paradigm gdb would grab any memory
in the inferior until it knew that it needed to.

In the case of the protected memory system, where
possible, an anonymous mmap call grabbing a few
megabytes might be significantly less invasive.

/john

Re: malloc in inferior

[Daniel Jacobowitz]

On Thu, May 29, 2003 at 01:18:23PM -0400, John S. Yates, Jr. wrote:
> From: "Daniel Jacobowitz" <drow@mvista.com>
> 
> [..SNIP..]
> 
> > > Is there anything short of calling a function in the
> > > target that requires materialization in the inferior?
> > > I can perform an enormous amount of debugging without
> > > ever thinking about trying to call a function.
> > 
> > What can you usefully do with strings that doesn't communicate them to
> > the inferior?
> > 
> > For instance, assigning "set x = "abc"" must materialize it in the
> > inferior.
> 
> Well as it so happens I was writing a "user-defined
> command" to walk from a task control block out 3
> levels.  My command had to guard against instances
> when outer levels of the structure did not exist.
> In such cases it tried to provide a clear diagnostic.
> The task control block contains an char tcb_name[8]
> member.  Since at times there might not even be a
> task running there might not be a valid task name.
> Thus I had
> 
> $task_name = ""      // even this calls malloc
> $tcb = 0
> $ptr1 = 0
> $ptr2 = 0
> if TCD_Current_Task
>     $tcb = TCD_Current_Task
>     $task_name = TCD_Current_Task->tcb_name
> else
>     printf "no current task\n"
> end
> 
> if $tcb
>     $ptr1 = $tcb->tcb_ptr1
>     if ! $ptr1
>         print "task %s: tcb_ptr1 is null\n",$task_name
>     end
> end
> 
> if $ptr1
>     $ptr2 = $ptr1->xxx_ptr2
>     if ! $ptr2
>         print "task %s: xxx_ptr2 is null\n",$task_name
>     end
> end
> 
> ...
> 
> [..SNIP..]
> 
> > > I think this suggestion got missed.  Instead of today's
> > > immediate materialization in the inferior against the
> > > possibility that the value might be required there in
> > > the future why not use a lazy approach?  Before calling
> > > an inferior function push down any accessible objects.
> > 
> > I didn't miss it; see above.  It would have to happen every time the
> > inferior is _resumed_, too.
> 
> No.  An object is only accessible in the inferior
> if its address has been 
> 
>   1) manifested (always true for string literals)
>   2) supplied to the inferior via assignment (to
>      inferior storage) or as an argument to an
>      inferior function call
> 
> [..SNIP..]

Hmm.  This might be possible.

Again, do you have a concrete example where GDB calls malloc() other
than strings?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: malloc in inferior

[Andrew Cagney]

> 
> Hmm.  This might be possible.
> 
> Again, do you have a concrete example where GDB calls malloc() other
> than strings?

Function descriptors, as with the xstormy16 and AIX.

Andrew

Re: malloc in inferior

[Alain Magloire]

> 
> Hmm.  This might be possible.
> 
> Again, do you have a concrete example where GDB calls malloc() other
> than strings?
> 

(gdb) p {1, 2, 3}


Note:  I did not follow the discussion/thread

Re: malloc in inferior

[John S. Yates, Jr.]

From: "Daniel Jacobowitz" <drow@mvista.com>
Sent: Thursday, May 29, 2003 1:24 PM

[..SNIP..]

> Again, do you have a concrete example where GDB calls malloc() other
> than strings?

Had to think a bit.  It obviously comes down to the
issue of needing the address of a value, as opposed
to an lvalue that already exists in the inferior.

This is obviously a bit more obscure than the mere
mention of a quoted string, but how about passing a
literal to a const-reference formal parameter?

/john

Re: malloc in inferior

[John S. Yates, Jr.]

From: "Paul Koning" <pkoning@equallogic.com>
Sent: Thursday, May 29, 2003 1:24 PM


> Are you talking about remote target debug?  I don't know of anything
> that uses malloc in the remote target protocol implementations I've
> seen.   That ignores function call (which I've never used, it doesn't
> seem to work in any implementation I've ever worked on).

Paul,

I work in an environment with a number of senior engineers
each with decades of experience doing OS and embedded systems
work.  An informal poll indicates that none of them has ever
seen gdb's function call capability work reliably.

On reflection I think that this is because RSP hides from the
stub the fact that a continue is being performed on behalf of
a gdb call versus an actual continue of the stopped application.
These users' typical expectations are that a gdb call should be
utterly uninvaisive (principle of least astonishment).  This is
why the gdb stub executes in exception context with interrupts
disabled.  Having a call to a debug dump utility restore full
thread context including reenabling interrupts, triggering who
knows what churning of carefully inspected state, makes gdb's
call capability just too risky for these developers.

This only makes invisible gdb calls even more pernicious.  Some
of the developers I talked to were aware of the malloc behavior
thought none were able to articulate precisely the conditions
under which it occurs.  They simply chalk it up to gdb flakiness
and restrict themselves to some collection of debugging actions
that experience has shown to be reliable.

/john

Re: malloc in inferior

[Andrew Cagney]

> 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.

That wouldn't work.  A user needs to be able to cut/paste arbitrary C 
source code into the GDB console and have it just work.

Given that most users don't even realize that the malloc is being 
called, I think it is working well.

>  Or make
> it a set option.  I'm not sure how popular that idea would be; anyone
> else have a comment?

A set option, or (discussed previously) allocated lazy fashion.

Andrew