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

[Philipp Burch]

Hi Uwe!

On 08/23/2013 10:53 AM, Uwe Bonnes wrote:
>>>>>> "Philipp" == Philipp Burch <phip at hb9etc.ch> writes:
>
>      Philipp> Hi Harald!  On 08/22/2013 03:41 PM, Harald Kipp wrote:
>      >> Hi Philipp,
>      >>
>      >> Although I'm the author of a large part here, I have the same problem
>      >> following the initial intention. That code is quite old. Last
>      >> relevant changes had been done in r1513, more than 7 years ago.
>      >>
>      >> This essential kernel code is used by all applications and it is most
>      >> unlikely, that a bug survived for such a long time. However, assuming
>
>      Philipp> Please don't understand me wrong, I'm not blaming you or Nut/OS
>      Philipp> for this bug. I just can't continue with debugging in a
>      Philipp> sensible way as long as I don't know how those things are
>      Philipp> supposed to work.  It is not particularly likely that my code
>      Philipp> overwrites exactly this single word in the NUTTHREADINFO
>      Philipp> structure, but also not impossible.
>
> If one specified word is overwritten, what about setting a watch on that
> word in the debugger?

Well, that would be too easy, wouldn't it? ;)
The problem is that the jlink (or the Cortex-M3) does not support 
conditional break-/watchpoints. So if I place a watch on it, then the 
debugger will stop there whenever the scheduler kicks in. Enabling the 
watchpoint when issueing the offending command could help with this, but 
as said earlier, the bug does not show up if the program is stopped in 
there.

Anyway, with the comments from Harald at hand, I'll investigate somewhat 
further.

Regards,
Philipp