Re: [lwip-devel] lwIP, FreeRTOS, STM32: SSL client "hangs" on semaphore take using infinite timeout

[bulek44]

address@hidden wrote
> "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.
> 
> 
>> #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
> 
> _______________________________________________
> lwip-devel mailing list

> lwip-devel@

> https://lists.nongnu.org/mailman/listinfo/lwip-devel

Hello,

thanks for the answer... It seems I need to explore further... It's hard to
say, what could take that mutex, since I have only one task using LwIP
(DHCP, network setup, then SSL communication - in here it hangs),
particularly sending/reading from socket...

The only thing that comes to my mind is that I have enabled 
/LWIP_NETIF_LINK_CALLBACK (Callback Function on Interface Link Changes)
LWIP_NETIF_LINK_CALLBACK Parameter Description: Set parameter allow to
support a callback function from an interface whenever the link changes
(i.e., link down). Dependency: None./

Is there a chance that if link status changes that somehow this callback
could cause this problem?
Not sure under which task that callback is started...

Is there anything other internal in LwIP that could take the mutex ?

Are there any rules regarding calling LwIP functions from other tasks
described somewhere (should I use mutexes) - i will actually use only link
change related callbacks - nothing else ?

Thanks in advance,
regards,
Bulek







--
Sent from: http://lwip.100.n7.nabble.com/lwip-devel-f11621.html