Skip to content

fix negative percentage and corrupt pgrogress par on large builds#535

Closed
jp-embedded wants to merge 3 commits into
gittup:masterfrom
jp-embedded:progress-overflow
Closed

fix negative percentage and corrupt pgrogress par on large builds#535
jp-embedded wants to merge 3 commits into
gittup:masterfrom
jp-embedded:progress-overflow

Conversation

@jp-embedded

Copy link
Copy Markdown

Progress bar overflow fix

Problem:
Large builds could make the progress percentage negative and corrupt the
progress bar output. The progress code calculated percentages with int
arithmetic, for example sum * 100 / total. Once the completed job count was
large enough, sum * 100 could overflow a signed int before the division. The
overflowed negative percentage was then used to calculate the filled portion of
the progress bar. That could produce a negative fill width and an invalid buffer
offset in the printf call that renders the bar, causing garbled characters.

Fix:
The percentage calculation now uses wider arithmetic for count-based progress
and stores time-based progress totals in time_t, matching the graph's total
mtime type. The computed percentage is clamped to the display range 0..100.
The rendered progress bar fill length is also clamped to 0..max before it is
used as a printf precision or buffer offset.

Result:
The progress percentage no longer wraps negative on large projects, and the
progress bar cannot render with negative widths or out-of-range buffer offsets
even if the completed count temporarily exceeds the expected total.

@gittup

gittup commented Jul 11, 2026

Copy link
Copy Markdown
Owner

I merged the fix in, but the test case doesn't seem to be working correctly (it passes even before the change). I'm getting this for .tup/progress-output:

[ tup ] [0.000s] Scanning filesystem...
[ tup ] [0.019s] Reading in new environment variables...
[ tup ] [0.019s] No Tupfiles to parse.
[ tup ] [0.019s] No files to delete.
[ tup ] [0.019s] Executing Commands...
 2) [0.002s] touch out1
 1) [0.002s] touch out2
 0) [0.001s] touch out3
 [...]   4%
[ tup ] [0.044s] Updated.

And this for .tup/progress-lines:

 [   ]   0%
 [.  ] -14%
 [.  ] -14%
 [.. ]  18%
 [.. ]  18%
 [...]   4%

(which is obviously wrong!) Your patch fixes it so the numbers are positive, but the test case doesn't seem to be verifying that.

@jp-embedded

Copy link
Copy Markdown
Author

ok thanks. Sorry for that. I will have a closer look at the test.

@jp-embedded

Copy link
Copy Markdown
Author

Fixed the test. Also added a test for color mode because it behaves differently

@gittup

gittup commented Jul 18, 2026

Copy link
Copy Markdown
Owner

Merged, thanks for the fixes!

@gittup gittup closed this Jul 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants