Misleading Error Message: Not allowed in ISR context when hard fault happens before default_console() is called for first time

[desowin]

Description of defect

Misleading Error Message: Not allowed in ISR context when hard fault happens before default_console() is called for first time

Easiest way to reproduce is to do NULL pointer dereference in class constructor and create statically allocated object of this class. The Hard Fault handler will collect the information and try to print it. However, as it is the first time default_console() is executing, the Hard Fault won't get printed because the Hard Fault handler will fail to acquire singleton mutex when constructing the console object in default_console().

Thus instead of Hard Fault message, you get completely misleading

++ MbedOS Error Info ++ Error Status: 0x80010133 Code: 307 Module: 1 Error Message: Mutex: 0x200284B4, Not allowed in ISR context Location: 0x8032257 Error Value: 0x200284B4 Current Thread: main Id: 0x2001AAA0 Entry: 0x8031FB7 StackSize: 0x1000 StackMem: 0x20027480 SP: 0x2004FD88 For more info, visit: https://mbed.com/s/error?error=0x80010133&tgt=DISCO_F746NG -- MbedOS Error Info --

and if you look into map file you'll notice that the Mutex: 0x200284B4 refers to singleton_mutex_obj.

The workaround is to ensure that default_console() gets called prior to the HardFault, but you need atleast good guess to do it.

Target(s) affected by this defect ?

ST 32F746GDISCOVERY

Toolchain(s) (name and version) displaying this defect ?

GNU Tools ARM Embedded 7 2018-q2-update

What version of Mbed-os are you using (tag or sha) ?

mbed-os-5.12.4

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

n/a

How is this defect reproduced ?

See description

[0xc0170]

@desowin What is your Mbed OS SHA you tested it with ? I recall there was similar issue and was fixed on master.

[desowin]

The mbed-os version I use is 73f096399b4cda1f780b140c87afad9446047432, which is tagged as mbed-os-5.12.4

[kjbracey]

I think the fix is something along the lines of mbed_fault_handler manipulating the error_in_progress flag that mbed_error does, or having its own equivalent.

That trap is suppressed if mbed_error is called from IRQ handler, but not if it's a direct fault handler.

I'm not quite sure how to structure the change though - mbed_error in turn suppresses some of its behaviour if it sees error_in_progress set.

Something like this would work, but it's ugly:

mbed_fault_handler
{
    bool old_flag = core_util_atomic_exchange_bool(&error_in_progress, true);
    do context prints
    core_util_atomic_store_bool(&error_in_progress, old_flag);
    mbed_error(xxx);
}

[0xc0170]

cc @ARMmbed/mbed-os-core

[ciarmcom]

@desowin thank you for raising this issue.Please take a look at the following comments:

Could you add some more detail to the description? A good description should be at least 25 words. What target(s) are you using? What toolchain(s) are you using? What version of Mbed OS are you using (tag or sha)? It would help if you could also specify the versions of any tools you are using? How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered. Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[desowin]

Could you add some more detail to the description? A good description should be at least 25 words.

I think the description is adequate.

What target(s) are you using?

ST 32F746GDISCOVERY

What toolchain(s) are you using?

GCC ARM

What version of Mbed OS are you using (tag or sha)?

73f0963, which is tagged as mbed-os-5.12.4

It would help if you could also specify the versions of any tools you are using?

GNU Tools ARM Embedded 7 2018-q2-update

How can we reproduce your issue?

Easiest way to reproduce is to do NULL pointer dereference in class constructor and create statically allocated object of this class.

[adbridge]

We've updated our automation, I will fix the requirements .

[adbridge]

@desowin could you confirm if this is still an issue for you on Mbed 6 ? Mbed 5 (other than 5,15) is no longer supported.

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2463

[ciarmcom]

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.