Weird happenings with printf.
Thomas.Doerfler at imd-systems.de
Wed Oct 7 14:24:30 UTC 2009
it really depends on the debug method you are using. In many systems,
gdb will set a global breakpoint when doing high-level steps. And IF
your task gets rescheduled (which may happen during debug and WILL
happen e.g. when waiting for interrupt-driven IO), then another task may
hit the breakpoint that has been laid out for YOUR task.
Setting task-specific breakpoints may help. Making sure, that only one
task enters the functions to be debugged will also help.
Hope this helps :-),
Nick Thomas wrote:
> I know this isn't much to go on,
> But, I am seeing a problem with a function which never returns.
> The function gets called, and then goes into a printf call, which never
> Using GDB, I can step through the code, and I see that it goes into 'puts'
> function from newlib/libc/stdio/puts.c .
> (The printf just has some text, no formatting, so I guess the compiler
> changed this 'puts').
> After a few more steps it goes into _puts_r (at line 81 of puts.c).
> At the next step, it goes into strlen function, but with a completely
> different stack frame!!!
> The text I was hoping to print has changed to some other text, from another
> function, in a different task!
> And now execution continues in this other task. So my original task is hung.
> Any ideas what is going on here? I am clueless.
> Has my task been rescheduled, and can this happen when stepping through the
> code in the debugger?
> I increased task stack sizes, but that made no difference.
> In case this helps, I am using PPC 405 hardware.
> Help appreciated.
> Nick Thomas
> Email: nick.thomas at pixsan.com
> rtems-users mailing list
> rtems-users at rtems.org
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at:
More information about the users