[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-devel] lwIP, FreeRTOS, STM32: SSL client "hangs" on semaphore
From: |
Simon Goldschmidt |
Subject: |
Re: [lwip-devel] lwIP, FreeRTOS, STM32: SSL client "hangs" on semaphore take using infinite timeout |
Date: |
Thu, 5 Sep 2019 07:56:01 +0200 |
"bulek44" wrote:
> I've noticed and at last analyzed/debug the nasty situation, where my SSL
> client task "hangs" after few hours with no further action.
>
> I've analyzed the situation and it seems that it hangs on taking a semaphore
> with infinite timeout inside LwIP part.
>
>
> #1
> I was quite surprised, because I've noticed, that semaphore is taken
> (called) by using infinite timeout. That means that task will never resume
> or know that something is wrong (it seems to take semaphore to
> send a message through LwIP). Shouldn't such code always be written in more
> non-blocking manner and return in some finite time interval if no semaphore
> is available...
No. This is a mutex, not a semaphore. There's no way to specify which timeout
is OK and at which time an error should be raised. Seems you found a bug
somewhere, but adding a timeout to taking the core lock won't fix that.
>
>
> #2
> AFAIK, blocking calls should be avoided, particularly if they show potential
> to be blocking forever.
Well, no. Even for nonblocking sockets, an OS just doesn't work that way: at
some point you *have* to block to ensure thread synchronization.
>
>
> #3
> There is a setting in the LwIP code that enables/disables IP Core Locking -
> LWIP_TCPIP_CORE_LOCKING and triggers the use of semaphore.
> Has anyone any idea, what happens if I disable that setting ?
You'll get the message passing variant. lwip_write() will send a message
containing what to do to the tcpip_thread and block on a semaphore waiting
for the response.
That won't fix your bug, either.
You'll need to find out which task has locked the tcpip core mutex and why.
Regards,
Simon