Error print improvements #10358
Merged
Error print improvements #10358
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The length calculation in UARTSerial::write_unbuffered was wrong, meaning it would truncate output data to half length. This would show up if `platform.stdio-buffered-serial` was configured to true, `platform.stdio-convert-newlines` was still false - `mbed_error` crashes would be garbled. This wasn't usually spotted because applications generally have both settings false or both true, and if newline conversion is on, then `mbed_error_puts` writes 1 character at a time to FileHandle::write, avoiding the length error.
Assert failure took a critical section before calling `mbed_error`. There's no need to take a critical section on assert failure - mbed_error does not do this, and is designed to operate from normal contexts. Avoiding the critical section will improve the chances of console initialisation due to assert failure working nicely.
Prime the console outside the critical section, improving the chances of nice initialisation.
|
@kjbracey-arm, thank you for your changes. |
0xc0170
approved these changes
Apr 11, 2019
SenRamakri
suggested changes
Apr 12, 2019
Once a fatal error is in progress, it's not useful to trap RTX errors or mutex problems, so short-circuit the checks. This makes it more likely that we may be able to get the console initialised if it is being written to for the first time by `mbed_error` in a difficult context - such as an RTX error callback from inside an SVCall. For example, the one-line program osMutexAcquire(NULL, 0); will generate an RTX error trap, then `mbed_error` will try to call `write(STDERR_FILENO)` to print the error, which will prompt mbed_retarget to construct a singleton `UARTSerial`. This would trap in the mutex for the singleton or the construction of the UARTSerial itself, if we didn't allow this leniency. If we clear the mutex checks, then `UARTSerial::write_unbuffered` will work.
kjbracey
force-pushed
the
error_print_improvements
branch
from
67cfca4 to
b8e80dd
Compare
SenRamakri
approved these changes
Apr 15, 2019
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
This was referenced May 15, 2020
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Fixes two key problems:
mbed_errororMBED_ASSERTfailure could fail to output if the console had not previously been usedmbed_errororMBED_ASSERTfailure would be garbled ifplatform.stdio-buffered-serialwastruebutplatform.stdio-convert-newlineswasfalse.Getting the console initialized for the first time in a fatal crash situation is always going to be potentially dicey, but we can make a better effort.
(If a platform is really serious about getting crash information out of the serial port, they should make an effort to get it ready in advance. But we don't necessarily want to initialise it if they're not planning to use it in normal operation.)
Fixes #10344, fixes #10242.
Pull request type