fault during my timer testing

[wayen30]

hello
I found a fault during my timer testing.

zephyr version: 1.9.1
code:

_struct k_timer test_timer, test_timer2;
static void test_timeout_event(os_timer *timer)
{
}

static void test2_timeout_event(os_timer *timer)
{
    k_timer_start(&test_timer, K_MSEC(10), K_MSEC(20));
}

void test_timer(void)
{
    k_timer_init(&test_timer, test_timeout_event, NULL); 
    k_timer_init(&test_timer2, test2_timeout_event, NULL); 

    k_timer_start(&test_timer, K_MSEC(10), K_MSEC(20));  

    while(1) {
        k_timer_start(&test_timer2, K_MSEC(100), 0);  
        k_sleep(K_MSEC(1000));
    }
}

analysis:
when timer1 & timer2 expired in the same tick, timer1 & timer2 will be dequeue from _timeout_q to expired.
In timer2 callback function, k_timer_start(&test_timer, K_MSEC(10), K_MSEC(20)) will re-insert timer1 to _timeout_q. After timer2 callback function, the expired sys_dlist(in _handle_expired_timeouts()) has changed.
The callback of timer linked in the _timeout_q will be called in order. when run last timeout(_timeout_q which actually is not a timer structure)，run timeout->func will trigger a fault.

[andyross]

Confirmed on HEAD (the report was against 1.9 -- @wayen30 please try to validate against a recent version when reporting new bugs) with a little porting of the sample code. I can get a fault (inside the scheduler, implying a corrupt run queue) on x86, and on cortex_m3 I see a hang where the timeout handlers appear to run correctly, but the k_sleep() out of the main thread (sleep uses the same timeout framework internally) fails to wake up the second time it is called.

Unsurprisingly, adding logging to try to inspect things has the side effect of delaying timing and "fixing" the bug. Sigh.

The proximate cause seems to be the handling of more than one timeout in a single timer interrupt. We... don't actually seem to have a test for this condition, and if I adjust the numbers in the code above so they don't land at the same time it seems to work.

I hate to say it, but we probably should make this bug a P1. This is pretty bad if we can't handle arbitrary timeout scheduling robustly.

[findlayfeng]

new bug~