Pthread_cond_timedwait problem

Kernel
1

Hi, we are trying to find a cause of a HardFault in a STM32F427 application. The FreeRTOS is version 10.4.3 and we are using mixed POSIX and non-POSIX tasks/libraries.

We have tried a number of approaches, but we could not find the cause yet.

There is one thing that could lead to the cause: there is a task that use pthread_cond_timedwait with a timeout of 10 ticks, normally the function exits with ETIMEDOUT or a task giving the pthread_cond_signal and thats fine.

But sometimes the function exits with zero error, like if some task has given the cond_signal, but no other task did it, as far as I could check. I did this by checking in xQueueGenericSend if the semaphore in the conditional variable was accessed just before the problem occur.

I don’t know yet if this is directly related to the cause of the HardFault, but it seems like something is corrupting the memory somewhere, and this could lead to the cause.

Is this a good approach? Or there would be a better way to find why the pthread_cond_timedwait is exiting with zero without other task intentionally giving the cond_signal?

Thank you in advance.
Regards,

2

pthread_cond_signal is not something we provide and therefore, it is a bit hard to guess the cause of the error. Where did you get that implementation?

In terms of getting the details about hard fault, can you find out the instruction causing the hard fault by following these instructions - Debugging and diagnosing hard faults on ARM Cortex-M CPUs

This is another good document from ARM about analyzing hard faults: https://www.keil.com/appnotes/files/apnt209.pdf

Thanks.

3

Hi Gaurav,

Thanks for the response.

The implementation is from FreeRTOS+Labs

Following the documentation from here:
image

We have already followed the first link you mentioned, it was actually the first thing to do. But we were not able to find the cause. At the moment of the HardFault, at least the LR and PC are corrupted.

4

Hi,
Per the pthread_cond_wait manual it is allowed to return zero for no obvious reason to the caller (spurious wakeup) , and the suggested use case should be as follows:

while (! mypredicate(&t) && rc == 0) 
{          
        rc = pthread_cond_timedwait(&t.cond, &t.mn, &ts);
}

That being said I am not sure the implementation of FreeRTOS+LAB follows this spec closely or the internal condition for such behavior is even present, but lets be on the safe side and do it the standard way, if you haven’t already done so.

5

That sounds like a memory corruption and fault is most probably the result of a corruption happened earlier. Do you have configASERT, stack overflow check and malloc failed check enabled?

Thanks.

6

I’ll try to do this check, thanks!

7

configASSERT and stack overflow are enabled, malloc not. I’ll enable and see if something changes… Thanks!