[En-Nut-Discussion] NutThreadRemoveQueue clears runQueue to NULL
bob_s at pmdinc.com
Fri Aug 23 18:15:53 CEST 2013
I'm trying to reply to a digest of this topic, so excuse me if I'm messing
up the thread...
> This is correct, but in this case very hard to do. As I noted, already a
> slight change in the code (such as printing a few less characters to the
> UART) makes the bug disappear, so it's quite hard to reproduce it with a
> simple test application. But I suppose there's no other way than to
> incrementally remove functionality and check the behaviour after each
Behavior that changes when you make a small and seemingly insignificant
change in another part of your program is classic behavior of an
initialized variable, NULL pointer access (though on ARM I would expect an
exception in the case of a NULL pointer), or invalid memory access.
Invalid memory accesses can be to heap memory after it has been freed. Or
using a pointer to some function's local variables after that function has
exited (and deallocated its local vars from the stack).
Or perhaps one or more of your stacks is not large enough and is
overflowing? Try filling each stack area with a known pattern on startup
and then checking to see if they ever fill up.
Uwe's tip on setting a watch on that var is also good.
All of these are a royal pain to track down and fix.
Bob (apparently a lurker no more)
More information about the En-Nut-Discussion