Tracking issue for output synchronisation between mbed_trace, printf...

[ithinuel]

Description of defect

Target(s) affected by this defect ?

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

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

mbed-os-99.99.99

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

N/A

How is this defect reproduced ?

Have multiple threads using the stdout put using Greentea, printf, mbed_trace.

This is a tracking issue to discuss to possible solution(s) to the output synchronization problem.

Mbed-os currently provides several mutually unaware ways to output traces and log messages to either a specific output and/or a retargetable destination.

This creates friction during development :

• corrupted greentea kv token generates false negative during CI testing.
• decreased readability of log renders difficult the debugging multithreaded tests.
• lowers the quality of the developer experience.

Prior discussion on #9954.

[ithinuel]

For the background history, I faced this issue when trying to build a Network Interface driver for a wifi module.
The driver dispatches its events in its own thread and prints logs using mbed_trace. However, greentea uses direct RawSerial, unity putc and some (most) of the netsocket tests are using printf.
Trying to reconstruct the corrupted log of intermingled messages coming from various parts of the software was a hassle, hence the hack proposed in #9954.

[0Grit]

What is the IDEAL design and feature-set for the various serial debug, test, logging, command line interfaces?

How do we hack what exists to get on the path to that ideal?

[ciarmcom]

Thank you for raising this issue. Please note we have updated our policies and
now only defects should be raised directly in GitHub. Going forward questions and
enhancements will be considered in our forums, https://forums.mbed.com/ . If this
issue is still relevant please re-raise it there.
This GitHub issue will now be closed.

[40Grit]

@adbridge Can this be considered a defect so that the discussion #11861 can be addressed?

Or should it be considered a new feature and PR created to discuss and implement?

[adbridge]

@40Grit we can make an exception in this case I think.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2341

[40Grit]

@0xc0170 @kjbracey-arm @SeppoTakalo @kivaisan

@trowbridgec

What is the best long term solution.
We have no fear of getting dirty to make it clean.

[0xc0170]

What is the best long term solution.

@ARMmbed/mbed-os-core Please review

[kivaisan]

cc: @AriParkkila
Could we get swo support for Daplink? And use that for mbed-os internal traces? That would probably solve the problem with Greentea which is really pain in the ass if you need to debug some test failures.

[0Grit]

Sure would be nice but not all hic's support swo though? Possibly not all targets hook it up either?

[AGlass0fMilk]

Possibly not all targets hook it up either?

(Including Cortex-M0)

[ciarmcom]

@ithinuel 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.

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[0Grit]

@kjbracey-arm @AGlass0fMilk @trowbridgec is this still an issue in os6?

[0xc0170]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

Sorry for the too many pokes here, we will fix the bot.

[0Grit]

Bot has been leading to me bumping the stale issues a little more vigorously. So maybe just extend it to 10 days?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ithinuel]

@adbridge As far as I know this hasn't been fixed yet.

@0xc0170 Np, GH is too noisy so it's filtered out anyway ;)

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

[ciarmcom]

@ithinuel it has been 5 days since the last reminder. Could you please update the issue header as previously requested?

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

[ithinuel]

I (finally) updated the description to please the Bot Overlord :)

As far as I know this is definitely still an issue in Mbed 6.

[ghseb]

Hello, Im not sure if this is the right direction, but regarding resource conflicts between greentea and mbed_trace there might be the possibility to alter the configuration of mbed-trace in _GREENTEA_SETUP_COMMON in a way that a print function is set (via mbed_trace_print_function_set) that is capable of tunneling trace printouts via greentea's key-value protocol.

Related section:
https://github.com/ARMmbed/mbed-os/blob/master/features/frameworks/greentea-client/source/greentea_test_env.cpp#L85

For a short term fix (to avoid conflicts and false negative tests) it might make sense to temporary disable trace printouts right there.

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