[En-Nut-Discussion] NutThreadRemoveQueue clears runQueue to NULL

[Bob Shaver]

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

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)