Fixed issue 148 draw context stack overflow by fdesbiens · Pull Request #158 · eclipse-threadx/guix

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiens · 2026-06-01T21:25:38Z

No description provided.

All callers of _gx_canvas_drawing_initiate() must check the return value before calling draw functions or _gx_canvas_drawing_complete(). When GX_DRAW_NESTING_EXCEEDED is returned the context stack is NOT pushed, so calling _gx_canvas_drawing_complete() corrupts the outer context's nesting counter. Fix pattern (matching _gx_widget_children_draw.c reference impl): status = _gx_canvas_drawing_initiate(...); if (status == GX_SUCCESS) { draw(); _gx_canvas_drawing_complete(); } else if (status == GX_NO_VIEWS) { _gx_canvas_drawing_complete(); } // else: stack overflow or invalid memory -- do nothing Files fixed: - gx_animation_start.c - gx_animation_drag_tracking_start.c - gx_multi_line_text_view_text_draw.c - gx_multi_line_text_input_draw.c - gx_rich_text_view_text_draw.c - gx_single_line_text_input_draw.c - gx_radial_progress_bar_background_draw.c (GX_BRUSH_ALPHA_SUPPORT path) - gx_widget_block_move.c - gx_system_canvas_refresh.c (partial and non-partial paths) - gx_system_error_process.c (Copilot attribution only; functional changes via eclipse-threadx#156) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…k overflow Tests that _gx_canvas_drawing_initiate() overflow does not corrupt the draw context state: 1. Overflow detection: GX_DRAW_NESTING_EXCEEDED returned at max depth (GX_MAX_CONTEXT_NESTING = 8 levels). 2. No state corruption: gx_canvas_draw_nesting and _gx_system_current_draw_context are unchanged after overflow. 3. Caller regression (_gx_widget_block_move): does not corrupt nesting counter or context pointer when overflow occurs at max depth. This would fail against the pre-fix code, which called _gx_canvas_drawing_complete() unconditionally. 4. Full unwind: gx_canvas_draw_nesting == 0 and context pointer == NULL after GX_MAX_CONTEXT_NESTING calls to gx_canvas_drawing_complete(). 5. Recovery: a fresh drawing initiate/complete pair succeeds after full unwind. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

…ng (#175) Commit 8a35f69 (#158) made _gx_animation_start() assign the return value of _gx_canvas_drawing_initiate() to its local "status" variable. That variable is both the value returned to the caller and the flag that gates linking the animation into the active list, so the drawing status leaked into the completion status. _gx_widget_show() releases the view list of the animation root window on the line just above that call, so _gx_canvas_drawing_initiate() reports GX_NO_VIEWS every time an animation canvas is used. The animation was therefore never linked into _gx_system_animation_list, the frame timer was never started and _gx_animation_complete() never ran: no animation frames were produced and GX_ANIMATION_PUSH_STACK never pushed its target onto the screen stack. The drawing status is now held in a separate draw_status variable. The #148 guard that keeps _gx_canvas_drawing_complete() from being called after GX_DRAW_NESTING_EXCEEDED is preserved, while the completion status returned to the caller is left untouched. _gx_animation_drag_tracking_start() contains the identical block but returns GX_SUCCESS unconditionally, so it was not affected. Its variable is renamed to draw_status as well, with no change in behaviour, so the two functions cannot drift apart again. Verified on Linux with the default_build_coverage regression suite. Before the fix, matching CI run 28477318897 exactly: 447 guix_all_widgets_16bpp_canvas_animation SEGFAULT 457 guix_animation_complete golden_file_frame_id = 1, test_frame_id = 3 458 guix_animation_complete_push_stack Failed, no output After the fix all three pass and 730 of 732 tests pass. The two remaining failures, guix_ml_text_view_32bpp and guix_all_widgets_accordion_menu, are unrelated to animation and are diagnosed separately. No new regression test is added: guix_animation_complete, guix_animation_complete_push_stack and guix_all_widgets_16bpp_canvas_animation already cover this path and are the tests that caught the regression. No golden file is regenerated, since the change restores the recorded behaviour rather than altering it. guix_canvas_draw_nesting_overflow_no_output, the test added by #158, still passes. No documentation change is required: no public API or behaviour contract changes. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

The fix for issue #148 (#158) made every caller of _gx_canvas_drawing_initiate() skip its draw when the call returns GX_DRAW_NESTING_EXCEEDED. Four of those callers push a nested context on the widget they are already drawing, for one reason only: to narrow the clipping rectangle to the widget's client area. For them, skipping the draw turns a correct rendering into no rendering at all, which is what made guix_all_widgets_accordion_menu report "Frame 12 is different". The accordion menu screen of the all_widgets demo nests widgets nine levels deep - multi_level_accordion, menu_list, mla_menu_1_accordion, menu_list, text_view_3 - and _gx_system_canvas_refresh() consumes two contexts before the widget tree is walked, so the eight slots of GX_MAX_CONTEXT_NESTING are exhausted before _gx_multi_line_text_view_text_draw() can push its own. Raising the limit in a scratch build makes frame 12 match the existing golden file exactly, which shows that the golden records the correct rendering and that the text is now being lost rather than merely clipped differently. When the stack is full there is nothing to push, but the caller's context is still the right context to draw through: it was created for the same widget and differs only in its clipping rectangle. These four callers now narrow the caller's clipping rectangle, draw, and restore it, instead of dropping the draw. _gx_canvas_drawing_complete() is still not called on overflow, so the stack corruption that #158 fixed stays fixed. Applied to _gx_multi_line_text_view_text_draw, _gx_multi_line_text_input_draw, _gx_rich_text_view_text_draw and _gx_single_line_text_input_draw. _gx_widget_block_move and _gx_radial_progress_bar_background_draw are left alone: neither pushes a clip-only context on the widget being drawn. guix_canvas_draw_nesting_overflow_render_no_output closes the coverage gap that #158 left. guix_canvas_draw_nesting_overflow_no_output covers detection and state preservation; the new test covers what a caller must render: that the text is still drawn at maximum nesting depth, that the borrowed context is handed back with its nesting count, context pointer and clipping rectangle unchanged, and that the pixels match those produced when a nested context is available. Assisted-by: Claude Code (Opus 5) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

fdesbiensand others added 2 commits June 1, 2026 17:23

fdesbiens merged commit 8a35f69 into eclipse-threadx:devJun 1, 2026
1 check passed

fdesbiens deleted the fix/issue-148-draw-context-stack-overflow branch June 1, 2026 21:29

fdesbiens mentioned this pull request Jun 2, 2026
Buffer overflow on _gx_system_draw_context_stack[GX_MAX_CONTEXT_NESTING] #148
Closed

fdesbiens mentioned this pull request Aug 27, 2026
Fixed animation start regression that prevented animations from running #175
Merged

fdesbiens mentioned this pull request Aug 27, 2026
Fixed text being dropped when the draw context stack overflows #176
Merged

This was referenced Aug 27, 2026
_gx_system_canvas_refresh() leaks an internal drawing status through the public API #180
Open
_gx_widget_block_move() drops the repaint when the canvas has no views #181
Open
GX_MAX_CONTEXT_NESTING = 8 is too shallow for the shipped all_widgets demo #182
Open

Uh oh!

Conversation

fdesbiens commented Jun 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Jun 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Jun 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Jun 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Jun 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

fdesbiens commented Jun 1, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation