[lwip-devel] [bug #26405] Prematurely released semaphore causes lwip_select() to crash

[Konstantin]

Follow-up Comment #3, bug #26405 (project lwip):

Simon,
I don't think my port is a problem. It does indeed understand the initial
state, here is the sys_sem_new() I am using (modelled after a sample provided
with FreeRTOS):

sys_sem_t sys_sem_new(u8_t count)
    {
    xSemaphoreHandle xSemaphore;
    
    portENTER_CRITICAL();
    vSemaphoreCreateBinary( xSemaphore );
    if (count == 0)
        {
        xSemaphoreTake( xSemaphore, 1 );
        }
    portEXIT_CRITICAL();
    
    return xSemaphore;
    }


However, I think the problem may be that sys_sem_wait_timeout() may time out
(hence the name). (In my case, the timeout was quite short.)
I am positive that in my case, a condition occured when by the time
tcpip_thread signals selectsem, the application thread was already waiting in
sys_sem_wait(selectsem), and as soon as the semaphore was released, the OS
woke up the application thread which destroyed select_cb.sem.

    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/bugs/?26405>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/