Hi,
I think I've found reliable way to cause hardfault when executing nrf_log_frontend-dequeue() and most likely cause nrf_log modules to write outside of allocated buffer space while in deferred mode.
It happens on (at least) SDK13.1.0 with S132 4.0.2 and 4.0.4 compiled on Keil 5.23. I'm using custom nRF52832 board with J-Link OB but this can be also reproduced on nRF52-DK.
Attached please find minimal test example ble_app_crash.zip
It's ble_app_template with scheduler and deferred RTT logging enabled. To cause reliable hardfaults sdk_config.h included in the project should be used as the code stability depends on sizes of RTT buffers.
Crashing code is as follows:
//playing around with LOG_COUNTER_MAX results in code crashing or not
//31 --> initial crash
//1-24; 48-75 --> ok;
//25-47; 76 --> crash
#define LOG_COUNTER_MAX 31
static void log_fill_crash(void)
{
for(uint8_t i=0; i<LOG_COUNTER_MAX; i++)
{
static char buff[33];
memset(buff,0,sizeof(buff));
snprintf(buff,sizeof(buff),"X:0.12345 Y:-0.12345 Z:1.23456");
NRF_LOG_RAW_INFO("%s\r\n",nrf_log_push(buff));
}
}
Calling log_fill_crash() just before infinite loop in main() causes a hardfault as soon as NRF_LOG_PROCESS() is executed.
Changing LOG_COUNTER_MAX value results in different program behaviors. For 1-24 log output is correctly truncated, 25-47 gives a hardfault with varying amount of gibberish printed out. At least some of the values in 48-75 range result in correct behavior but 76 causes crash.
Could you please check if this is indeed a bug or maybe I'm just doing something wrong in my project setup?
