Skip to content

script: logging: Fix small bugs and add support for live log parsing from a file #93107

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

omrisarig13
Copy link

This PR contains 3 commits, all changing the log parser scripts.

The first commit add correct support to lengthed short-short and long-long arguments in the log ("%02hhX"). Currently, the log crashes when it tries to parse these valid formats, so this commit fixes this issue.

The second commit updates the current handling of non-full packets. This is an issue that exists when have live parsing of the logs - when the last read packet is not full, the parser would fail, and stop the parsing. This commit updates this handling to correctly handle this case, and keep parsing the packets correctly even when a non-full packet was received over the UART.

The third commit extends the functionality of the log_parser_uart to also support showing live log messages from files (and from stdin), making it possible to use the script with other interfaces than the UART interface.
This commit changes the file name, and the way it receives arguments - so it breaks backward compatibility of this script - I believe that this is an improvement to the script, and that it can be used by many more developers this way. I can re-work it so it is done in it's own script, if that makes more sense to you.

All the changes I've done are made to create support for these scripts to the project I'm working on, which have zephyr logging over RTT which are read with J-Link. I believe these are universal improvement to the script, which can be utilised by other people working with Zephyr as well.

Python does not support values of long-long (ll) or short-short (hh) in
string-formatting. The current parser is correctly removing the first "h"
or "l" from the format, to make it possible to correctly parse these
strings when they are in the dictionary.

However, the current implementation does not correctly handle the case of
having a number before the "ll" or "hh" argument - which is supported by
both C and Python.

This commit updates the parser to correctly handle these cases, by changing
the simple replace operator with a regex replace, which is able to
correctly handle this case.

Before this commit, the string of:
    "This is my long variable: %08llX"
will stay the same, which will throw a ValueError when parsing this
dictionary message:
    "ValueError: unsupported format character 'h' (0x68) at index ".
After this commit, the string will be correctly fixed to
    "This is my long variable: %08lX"
which is parsed correctly.

Signed-off-by: Omri Sarig <[email protected]>
Copy link

Hello @omrisarig13, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

The current implementation of the serial log parser is running in a loop -
every 2 seconds it checks if there is any information ready to be read, and
in this case, it reads this information and parses it.
In case the last packet of the information is not fully available, the
script will read only the first part of the packet, and will fail when
parsing, ending the run with an error.

This should not the be the case, as it is not an error to have only part
of the packet in the buffer.
This commit fixes this problem - now, instead of failing because the parser
does not have enough information, the parser will parse all the full
packets it have, and keep the last, partial packet in the queue, to be
parsed together with the next chunk of data.

This is done by updating the log parsers to return the amount of parsed
data when trying to parse the information, and updating the calling scripts
to correctly handle this new return value.
Additionally, the parser is now quietly failing in case of having a partial
message, and throw an exception for any other kind of error in the parsing
(instead of returning a boolean return code).

In addition to the partial packet handling, the current commit also do the
following, minor improvements:
* parserlib now fails by throwing an exception, instead of exiting - this
  is done to make it possible to choose a different handling for the errors
  from the calling code, if needed.
* The dictionary and parser are now created before the parse operation.
  This makes the uart parser more efficient, and also removes the
  previously duplicated messages of build id, target architecture and
  endianess (which was printed every time new information was received from
  the UART).

Signed-off-by: Omri Sarig <[email protected]>
@omrisarig13 omrisarig13 force-pushed the logging/dictionary-from-stdin branch from c47dcee to b551461 Compare July 14, 2025 14:12
@omrisarig13
Copy link
Author

Regarding the "Duplication on new code" - this is the case because of existing decision to split parser_v1 and parser_v3 to files that do not share base code - I tried to follow the current convention, which created this code-duplication.

I think that this makes sense with the current architecture, but please let me know if you disagree.

Copy link
Member

@dcpleung dcpleung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you make log_parser_uart.py an alias to live_log_parser.py? This is to avoid breaking anyone who depends on this in scripts. Also add an entry to the migration guide so we can properly deprecate log_parser_uart.py.

Create a new, generic parser, that is able to parse dictionary logs live
- showing the messages as they are received from the device.

This functionality previously existed only for reading the log from a UART.
With the new script, the functionality is extended to be able to also read
the log from a file or stdin.
Additionally, the script is written in an extend-able way, making it simple
to support more input sources in the future.

The new script contains a better version of the live functionality than the
old script of log_parser_uart script, therefore, the old script has been
deprecated.
The UART script is still available, and will work by invoking the new
implementation with relevant arguments translation, however, it should
ideally not be used any longer, and should be removed from a future
release.

Signed-off-by: Omri Sarig <[email protected]>
@omrisarig13 omrisarig13 force-pushed the logging/dictionary-from-stdin branch from b551461 to 24db2bb Compare July 15, 2025 06:17
@github-actions github-actions bot added the Release Notes To be mentioned in the release notes label Jul 15, 2025
@omrisarig13
Copy link
Author

@dcpleung Thanks for the fast review.

That's a very good idea - I've re-done the last commit, leaving the interface of log_parser_uart.py intact, but it now prints a deprecation message (and works internally by just invoking the live_log_parser.py scirpt).

I've added the relevant message to the migration guide for 4.2 - I'm not sure if that's the right place, or if it's too late and should be moved to 4.3.
Please let me know if you want me to move it.

@omrisarig13 omrisarig13 requested a review from dcpleung July 15, 2025 06:23
Copy link

@dcpleung
Copy link
Member

I think it is too late to get into 4.2. Could you move the migration guide entry to 4.3?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Logging Release Notes To be mentioned in the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants