Repository navigation
Clamp idle timeouts to the int32 millisecond range - #11353
rand0mdud3 wants to merge 1 commit into
Conversation
f914697 to
cdb4b32
Compare
johnpippett
left a comment
There was a problem hiding this comment.
The timeout correction gave the required results in the automatic checks below. The checks found no regression in these cases.
Head: cdb4b3289ba09316d46c5026e3439617a93ddc08
Base: b5589faaf80c6f87c07d4560fca37c4a81722f28
Each revision had these checks:
test/shell.d/idle-test.sh: 9 assertions on the base and 12 on the head, all with the required results.test/shell.d/system-lock-test.sh: the assertion gave the required result with command stubs.- The
IdleModel.jsfile at each revision: 32 specified cases and 10,000 generated finite values, all with the required results. - QML integer properties and
Timer.interval: 33 configurations per revision, including both deadline orders and values at the integer limit.
The QML fixture imported the JavaScript module from each source revision. Its scalar properties and interval expressions came directly from Service.qml. Both timers stayed stopped during the checks. The fixture did not load the idle service or create an IdleMonitor.
All head intervals stayed within the signed 32-bit millisecond range. Thirteen ordinary, incorrect-input, and type-conversion configurations gave the same results on both revisions.
Environment: Linux x86_64, Qt 6.11.2, Node 26.7.0, and bubblewrap 0.11.2. Each test process had an empty home directory and no network or desktop access.
The test scope did not include live idle behavior, timer operation, log growth, or lock-screen behavior. It did not include graphical acceptance tests.
Codex agents did these tests and prepared this review.
|
Automated duplication check: this pull request looks similar to #7578, which covers the same idle timeout int32 clamp. I keep that one open and close this one to consolidate review. If you feel this is the wrong decision, please open the PR again with a note on the difference. |
Fixes #11329.
secondsFromConfig had no upper bound, so a large idle.lock (e.g. 999999999, used as effectively-never) overflowed QML Timer.interval (32-bit signed ms) into a negative number. Qt clamps that to 1ms and the timer free-runs, spamming QBasicTimer warnings at ~1kHz (~1GB/session) and filling /run/user tmpfs.
Verified for real on MacBookPro11,5, not just mocks. Repro: screensaver 10 + lock 999999999, restart shell, stay idle 2 min: fresh log grew 0 to 9.8MB with 82,885 QBasicTimer warnings and climbing. Then the same one-line clamp applied to the installed copy, same repro: full window, 0 warnings, ~6KB log, no spurious lock. Installed file restored byte-identical afterwards (checksum-verified) and stock config (150/300) put back.