log-d678: don't spin forever when the log buffer allocation fails - #296
Open
ServerDestroyer wants to merge 2 commits into
Open
log-d678: don't spin forever when the log buffer allocation fails#296ServerDestroyer wants to merge 2 commits into
ServerDestroyer wants to merge 2 commits into
Conversation
log_start() ended with "while (!buf);". On models that allocate the buffer with _AllocateMemory() (everything without a hardcoded address), an allocation failure therefore hangs boot_post_init_task in an infinite loop - no LED activity, no display, indistinguishable from a bricked camera. That failure is reachable in practice: with this logger wired into a full 6D2.111 ML build, GetMemoryInformation() reported 0 total / 0 free at log_start() time and every _AllocateMemory() from 2 MB down to 128 KB failed (measured through the qemu monitor via the logger's own before/after pool counters; reproduced on four consecutive builds). Bail out instead: set buf_size = 0 and return before patching DebugMsg or installing the ISR hooks. my_DebugMsg() already drops everything while buf is NULL, and log_finish() now returns early in the same case (nothing was installed, so there is nothing to undo or save). The camera then boots normally, just without a startup log - losing the log is the cheaper failure.
char task_name_padded[11] = " " (11 spaces) leaves no room for the terminator, so the array starts out unterminated. Not a runtime bug - the snprintf below always writes a NUL before the first read - but gcc 15 rejects the initializer under -Werror=unterminated-string-initialization, so the file no longer compiles with current toolchains. Size the array for the terminator.
Owner
|
Why is it preferable to proceed when logging is impossible, with a build explictly opting into logging? (note that the qprintf calls before the while(!buf) will show the cause of the problem in qemu build using CONFIG_QEMU=y). |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
log_start()spins inwhile (!buf);if the initial log-buffer allocation fails. Since this runs fromboot_post_init_task, an allocation failure presents as an apparently-bricked camera — black screen, no response, nothing to debug with.The failure is reachable in practice: we hit it on the 6D2 while investigating startup logging (allocation failing at
log_start()time under certain feature combinations). With this change the logger degrades gracefully — setsbuf_size = 0and returns, so the camera boots normally, just without a startup log.Also fixes a gcc 15 build error in the same file (
task_name_padded[11]has no room for the NUL terminator;-Werror=unterminated-string-initialization).🤖 Generated with Claude Code