logging can't dump exceptions without losing data with CONFIG_LOG_PRINTK

[andrewboie]

I was making some changes to samples/subsys/logging/logger when I noticed that my exception printouts were garbled:

***** General Protection Fault
***** Exception code: 0x0
Current thread ID = 0x00400000
eax: 0x00400100, ebx: 0x004022d0, ecx: 0x0040231c, edx: 0x004022dc
esi: 0x00000000, edi: 0x00402     0x0000343f (0x400100)
     0x0000368a (0x402304)
     0x00002fca (0x0)
     0x00002938 (0x9919)
     0x000014c8 (0x9919)
     0x000023fd (0x0)
Fatal fault in thread 0x00400000! Aborting.

We're missing some of the call trace and the register dump.

[nordic-krch]

yes, that is because that part is called before log_panic occurs. In that case, printk content is formatted to a stirng and stored in the logger buffer. Since the content is stored and not log message like in standard logs it consumes more space in the buffer (approx string length + >20bytes). With series of such messages buffer can get full quite fast.

There are two options:

• bigger buffer
• rework handling of printk messages to be exactly like log_messages but without formatting (e.g. ERR level without formatting.). In that case user must take same care as in case of the logger to use log_strdup for transient strings but there are many benefits - less ram used, much faster (same speed as logging, 10-20 times faster).

[carlescufi]

@andrewboie and @nordic-krch is this still relevant or can we close it?

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.