Stuck in a 'for' loop in _Watchdog_Insert.

[Gedare Bloom]

I had a similar bug but it was because I was changing some code in
task management.  I had interrupts enabled between when a task was
killed and the task's watchdog was removed from the chain.  This
caused corruption of the watchdog chain.  Maybe you have some similar
situation?

-Gedare

On Thu, May 20, 2010 at 11:13 AM, Nick Thomas <nick.thomas at pixsan.com> wrote:
>
>> Nick,
>>
>> unfortunately you do not provide real information about the system you
>> are using. So it is really difficult to help you :-(
>>
>
> Hi Thomas,
>
> The system I am using is RTEMS 4.7.1. It's code in watchdoginsert.c,
> watchdogadjust.c and watchdogtickle.c, these are all in cpukit/score/src.
> So, they are not specific to any hardware.
>
> There is already a comment in _Watchdog_Tickle in watchdogtickle.c which
> says this:
>
>  /*
>   * For some reason, on rare occasions the_watchdog->delta_interval
>   * of the head of the watchdog chain is 0.  Before this test was
>   * added, on these occasions an event (which usually was supposed
>   * to have a timeout of 1 tick would have a delta_interval of 0, which
>   * would be decremented to 0xFFFFFFFF by the unprotected
>   * "the_watchdog->delta_interval--;" operation.
>   * This would mean the event would not timeout, and also the chain would
>   * be blocked, because a timeout with a very high number would be at the
>   * head, rather than at the end.
>   * The test "if (the_watchdog->delta_interval != 0)"
>   * here prevents this from occuring.
>   *
>   * We were not able to categorically identify the situation that causes
>   * this, but proved it to be true empirically.  So this check causes
>   * correct behaviour in this circumstance.
>   *
>   * The belief is that a race condition exists whereby an event at the head
>   * of the chain is removed (by a pending ISR or higher priority task)
>   * during the _ISR_Flash( level ); in _Watchdog_Insert, but the watchdog
>   * to be inserted has already had its delta_interval adjusted to 0, and
>   * so is added to the head of the chain with a delta_interval of 0.
>   *
>   * Steven Johnson - 12/2005 (gcc-3.2.3 -O3 on powerpc)
>   */
>
> This describes pretty much the behavior I am seeing, i.e.
> the_watchdog->delta_interval == 0.
>
> However, contrary to the above comments - removing the _ISR_Flash( level )
> call from _Watchdog_Insert doesn't fix the issue.
>
> I understand why I am stuck in this 'for' loop when this happens, but I
> don't understand why this code doesn't break out of it when we get to the
> end of the linked list:
>
> if ( delta_interval == 0 || !_Watchdog_Next( after ) )
>       break;
>
> i.e. why doesn't !_Watchdog_Next( after ) return NULL at the end of the
> list?
>
> For some reason it points back to itself!!!!! So the for loop is still
> engaged.
>
>
> Regards
>
> Nick
>
>
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-users
>