GCC - hardfault in mktime with irq disabled

[svastm]

I don't know if some other standard function are affected but it seems that every time we call mktime() in a critical section, with GCC only, an hardfault is fired. Both standard and nano libs seems to be affected. I tried with the NUCLEO_F303RE and NUCLEO_F429ZI and the mbed-cli to compile the tests.

mbed compile -m NUCLEO_F303RE -t GCC_ARM

with this main.cpp

#include "mbed.h"

int main()
{
    time_t t1, t2;
    printf("begin\n");

    struct tm timeinfo;
    timeinfo.tm_wday = 4;
    timeinfo.tm_mon  = 0;
    timeinfo.tm_mday = 1;
    timeinfo.tm_year = 70;
    timeinfo.tm_hour = 0;
    timeinfo.tm_min  = 0;
    timeinfo.tm_sec  = 5;
    // Daylight Saving Time information is not available
    timeinfo.tm_isdst  = -1;

    t1 = mktime(&timeinfo);
    printf("t1: %ld\n", t1);

    // __disable_irq();
    // printf("printf is ok ?\n");
    // __enable_irq();

    //core_util_critical_section_enter();
    __disable_irq();
    t2 = mktime(&timeinfo);
    __enable_irq();
    //core_util_critical_section_exit();

    printf("t2: %ld\n", t2);

    printf("end\n");
}

and the output, same result on GCC v5.3 and v4.9.

begin
t1: 5
printf is ok ?

An other thing that can be related, with ARM and IAR compilers, we can't use printf() in critical section (which should be the normal behaviour, the serial_api use interrupts) but with GCC the text is printed.

[svastm]

An update to add that the problem happen on mbed 5 and mbed 2 + RTOS but not on mbed 2. So the problem must come from the RTOS.

[sg-]

@c1728p9 I think we looked at this previously. Mind sharing what our thoughts were here?

[ciarmcom]

ARM Internal Ref: IOTMORF-461

[c1728p9]

Hi @svastm, a hardfault occurs because the gcc standard library (newlib) is internally using a mutex to protect global information. This causes a hardfault because a mutex is not allowed to be used inside a critical section. There should be no need for a critical section around mktime.

[svastm]

Hello,
I was investigating too and I reach the same conclusion. In the real application, I'm not responsible for enabling the critical section. Also i can't break a section just to use mktime().

We could consider to check the PRIMASK before using mutex.

TARGET_CORTEX_M/rt_CMSIS.c:1520

/// Wait until a Mutex becomes available
osStatus osMutexWait (osMutexId mutex_id, uint32_t millisec) {
  if (__get_IPSR() != 0U || __get_PRIMASK() != 0U) {
    return osErrorISR;                          // Not allowed in ISR and with interrupt disabled
  }
  return __svcMutexWait(mutex_id, millisec);
}

/// Release a Mutex that was obtained with osMutexWait
osStatus osMutexRelease (osMutexId mutex_id) {
  if (__get_IPSR() != 0U || __get_PRIMASK() != 0U) {
    return osErrorISR;                          // Not allowed in ISR and with interrupt disabled
  }
  return __svcMutexRelease(mutex_id);
}

I have no more error in mktime with this small fix.

[c1728p9]

Hi @svastm, a changes similar to that is being discussed here:
#2391

The problem with that is that it will mask errors. Since the mutex is never acquired, thread safety isn't provided. Even though the current thread will complete the call to mktime without being interrupted there could be another thread using the same global data that is not in a critical section. Since the second thread is relying on the mutex to protect this data, the first thread could interrupt an operation at any time since it won't block on any mutexes.

[svastm]

After the merge of #2391, I am able to run the small test code on a DISCO_F469NI.