mbed-trace enable makes thread overflow in GCC

[jeromecoutant]

Description of defect

Discussion started in #12416

Tests done on top of #12464 with NUCLEO_F767ZI and tests-netsocket-tcp

Goal is to check the maximum thread size of stm32_emac_thread:

	ARM	GCC
develop profile	216	232
develop profile + mbed-trace	368	856
debug profile	248	232
debug profile + mbed-trace	368	840

How can we explain so much difference in GCC ?

@kjbracey-arm @SeppoTakalo

Thx

Target(s) affected by this defect ?

All

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

GCC9

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

Master branch is indicated by 'mbed-os-99.99.99

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

None

How is this defect reproduced ?

None

[SeppoTakalo]

How is the stack sizes measured?

[jeromecoutant]

How is the stack sizes measured?

Greentea stats with with NUCLEO_F767ZI and tests-netsocket-tcp

[SeppoTakalo]

I don't know what Greentea stats is.. Do you mean Greentea tests?

If you just modify the stack size, and run the tests. Whether it crashes or not, does not mean that the stack overflow did not happen.
Or.. no I'm not sure, do we actually use some feature from RTX kernel that monitors stack overflows?

[SeppoTakalo]

Seems like we do enable the checking by default: https://github.com/ARMmbed/mbed-os/blob/master/rtos/source/TARGET_CORTEX/rtx5/RTX/Config/RTX_Config.h#L149

Watermarking and debugger would be another way to check how much the stack is used: https://github.com/ARMmbed/mbed-os/blob/master/rtos/source/TARGET_CORTEX/rtx5/RTX/Config/RTX_Config.h#L156

How did the test indicate that it was a stack overflow?

[jeromecoutant]

If you execute tests with mbed-os statistics enabled,
you will get some metrics in the console at the end of test cases:

See
https://github.com/ARMmbed/mbed-os/blob/master/features/frameworks/greentea-client/source/greentea_metrics.cpp

Question of this issue is to try to understand why:

• for ARM, enabling mbed-trace needs to increase thread size of 150 B
• for GCC, enabling mbed-trace needs to increase thread size of 620 B ?

Thx

[jeromecoutant]

How did the test indicate that it was a stack overflow?

Test is crashing in case of overflow :-)
In order to get stats the maximum size value, I increased the thread size value to be sure to execute the tests.

[SeppoTakalo]

Seems that the required hooks are there.. but this wonders me:
We ask the remaining stack space here: https://github.com/ARMmbed/mbed-os/blob/master/features/frameworks/greentea-client/source/greentea_metrics.cpp#L164

But that function is documented as follows:

/// Get available stack space of a thread based on stack watermark recording during execution.
/// \param[in]     thread_id     thread ID obtained by \ref osThreadNew or \ref osThreadGetId.
/// \return remaining stack space in bytes.
uint32_t osThreadGetStackSpace (osThreadId_t thread_id);

As I linked earlier, we don't have the watermarking enabled, so does it work at all?

If you have the board in hand, can you try enabling the RTX stack watermarking and re-running the tests?

[jeromecoutant]

I think RTX stack watermarking is already enabled, as I enable stats:

https://github.com/ARMmbed/mbed-os/blob/master/rtos/source/TARGET_CORTEX/mbed_rtx_conf.h#L69-L71

[adbridge]

@jeromecoutant Hi Jerome could you please fill in the missing information in the issue template, in the right fields? Our latest automation requires all the fields filled (or at least n/a or None if not relevant) before an issue will be mirrored to out internal issue database . Technically no work on an issue should happen until it is mirrored :)

[ciarmcom]

@jeromecoutant thank you for the update.It appears however that there is still some missing information:

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.

[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-2266

[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.