* malloc in inferior @ 2003-05-29 13:51 John S. Yates, Jr. 2003-05-29 15:27 ` Daniel Jacobowitz 0 siblings, 1 reply; 11+ messages in thread From: John S. Yates, Jr. @ 2003-05-29 13:51 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 13:51 malloc in inferior John S. Yates, Jr. @ 2003-05-29 15:27 ` Daniel Jacobowitz 2003-05-29 16:00 ` John S. Yates, Jr. 2003-05-29 16:42 ` Andrew Cagney 0 siblings, 2 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2003-05-29 15:27 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 15:27 ` Daniel Jacobowitz @ 2003-05-29 16:00 ` John S. Yates, Jr. 2003-05-29 16:09 ` Daniel Jacobowitz [not found] ` <16086.16988.657059.717389@pkoning.dev.equallogic.com> 2003-05-29 16:42 ` Andrew Cagney 1 sibling, 2 replies; 11+ messages in thread From: John S. Yates, Jr. @ 2003-05-29 16:00 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 16:00 ` John S. Yates, Jr. @ 2003-05-29 16:09 ` Daniel Jacobowitz 2003-05-29 17:18 ` John S. Yates, Jr. [not found] ` <16086.16988.657059.717389@pkoning.dev.equallogic.com> 1 sibling, 1 reply; 11+ messages in thread From: Daniel Jacobowitz @ 2003-05-29 16:09 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 16:09 ` Daniel Jacobowitz @ 2003-05-29 17:18 ` John S. Yates, Jr. 2003-05-29 17:24 ` Daniel Jacobowitz 0 siblings, 1 reply; 11+ messages in thread From: John S. Yates, Jr. @ 2003-05-29 17:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 17:18 ` John S. Yates, Jr. @ 2003-05-29 17:24 ` Daniel Jacobowitz 2003-05-29 18:18 ` Andrew Cagney ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Daniel Jacobowitz @ 2003-05-29 17:24 UTC (permalink / raw) To: John S. Yates, Jr.; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 17:24 ` Daniel Jacobowitz @ 2003-05-29 18:18 ` Andrew Cagney 2003-05-29 18:34 ` Alain Magloire 2003-05-30 13:12 ` John S. Yates, Jr. 2 siblings, 0 replies; 11+ messages in thread From: Andrew Cagney @ 2003-05-29 18:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: John S. Yates, Jr., gdb > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 17:24 ` Daniel Jacobowitz 2003-05-29 18:18 ` Andrew Cagney @ 2003-05-29 18:34 ` Alain Magloire 2003-05-30 13:12 ` John S. Yates, Jr. 2 siblings, 0 replies; 11+ messages in thread From: Alain Magloire @ 2003-05-29 18:34 UTC (permalink / raw) To: gdb > > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 17:24 ` Daniel Jacobowitz 2003-05-29 18:18 ` Andrew Cagney 2003-05-29 18:34 ` Alain Magloire @ 2003-05-30 13:12 ` John S. Yates, Jr. 2 siblings, 0 replies; 11+ messages in thread From: John S. Yates, Jr. @ 2003-05-30 13:12 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <16086.16988.657059.717389@pkoning.dev.equallogic.com>]
* Re: malloc in inferior [not found] ` <16086.16988.657059.717389@pkoning.dev.equallogic.com> @ 2003-05-30 13:03 ` John S. Yates, Jr. 0 siblings, 0 replies; 11+ messages in thread From: John S. Yates, Jr. @ 2003-05-30 13:03 UTC (permalink / raw) To: Paul Koning; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: malloc in inferior 2003-05-29 15:27 ` Daniel Jacobowitz 2003-05-29 16:00 ` John S. Yates, Jr. @ 2003-05-29 16:42 ` Andrew Cagney 1 sibling, 0 replies; 11+ messages in thread From: Andrew Cagney @ 2003-05-29 16:42 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: John S. Yates, Jr., gdb > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2003-05-30 13:12 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-05-29 13:51 malloc in inferior John S. Yates, Jr. 2003-05-29 15:27 ` Daniel Jacobowitz 2003-05-29 16:00 ` John S. Yates, Jr. 2003-05-29 16:09 ` Daniel Jacobowitz 2003-05-29 17:18 ` John S. Yates, Jr. 2003-05-29 17:24 ` Daniel Jacobowitz 2003-05-29 18:18 ` Andrew Cagney 2003-05-29 18:34 ` Alain Magloire 2003-05-30 13:12 ` John S. Yates, Jr. [not found] ` <16086.16988.657059.717389@pkoning.dev.equallogic.com> 2003-05-30 13:03 ` John S. Yates, Jr. 2003-05-29 16:42 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).