lwip sockets select crash
Posted: Mon Jun 15, 2015 12:07 pm
Hello,
The code I have running on top of lwip does a select on a UDP socket.
However this seems to go wrong at this line:
The first time the signal works without any problem, then for some reason it calls it a second time in that for loop and then comes in port_halt with the error message "inconsistent semaphore".
The lwip_select is only called once, however it goes the second time through the for loop in the event_callback function where it calls the signal, I have no idea why.
Also the next item in the list it puts itself to contains an invalid semaphore next value which probably causes the crash.
What is even more strange is that the next "scb" item which is used the second time to signal points to itself with prev and next attributes.
I have trouble understanding this behaviour, I would expect if I do a single select it only goes through the for loop once performs the signal and it's done.
But something seems to go wrong, could someone give me a pointer on this behaviour or why this might go wrong?
Another weird thing is that if I comment the reschedule in the signal it doesn't crash or if but a break after the first signal it also doesn't crash and can do multiple select after each other.
The code I have running on top of lwip does a select on a UDP socket.
However this seems to go wrong at this line:
Code: Select all
/* Don't call SYS_ARCH_UNPROTECT() before signaling the semaphore, as this might
lead to the select thread taking itself off the list, invalidagin the semaphore. */
/* CHIBIOS FIX: specific variant of this call to be called from within
a lock.*/
/* sys_sem_signal(&scb->sem);*/
sys_sem_signal_S(&scb->sem);
The first time the signal works without any problem, then for some reason it calls it a second time in that for loop and then comes in port_halt with the error message "inconsistent semaphore".
The lwip_select is only called once, however it goes the second time through the for loop in the event_callback function where it calls the signal, I have no idea why.
Also the next item in the list it puts itself to contains an invalid semaphore next value which probably causes the crash.
What is even more strange is that the next "scb" item which is used the second time to signal points to itself with prev and next attributes.
I have trouble understanding this behaviour, I would expect if I do a single select it only goes through the for loop once performs the signal and it's done.
But something seems to go wrong, could someone give me a pointer on this behaviour or why this might go wrong?
Another weird thing is that if I comment the reschedule in the signal it doesn't crash or if but a break after the first signal it also doesn't crash and can do multiple select after each other.
