Commit 9bfd44f
fix(battery): address Greptile race + backoff + burst-gating findings (#57)
* fix(battery): address greptile race + backoff-consistency + burst-gating
Follow-up to #56. Three Greptile findings:
1. P1 — mScanning = true was assigned outside the synchronized block
in MeterScanner.scanRunnable, opening a window where a concurrent
stopScan(false) (e.g. processScanResult on line 126) sees
mScanning == false, skips scanStopper(), and returns — leaving the
BLE scan active for the full 6.5 min scantimeout. Move
mScanning=true into the same synchronized block that clears
scanpending and resets currentwait so the state transition is
atomic.
2. P2 — currentwait is written under synchronized(MeterScanner.this)
but read in stopScan() without the lock (JMM data race). Declare
currentwait and scanpending volatile so the read in stopScan is
guaranteed to see the latest value without expanding the lock
scope.
3. P2 — onScanFailed (MeterScanner line 202) hard-coded
scanStarter(scaninterval) so the new exponential backoff in
currentwait was bypassed on BLE-stack-reported failures
(SCAN_FAILED_APPLICATION_REGISTRATION_FAILED /
SCAN_FAILED_INTERNAL_ERROR). Use currentwait so both failure paths
stay consistent and a stream of scan failures backs off up to
scanstartmaxwait (5 min) instead of always retrying in 60 s.
4. P2 (testlab.yml, discussion_r3489714891) — the inter-start burst
warning was nested inside 'if len(ble_starts) > len(ble_stops) +
1:'. A balanced but rapid cycle satisfied starts == stops and got
the 'balanced' line, hiding what could be a high-frequency
startScan burst. Hoist the delta computation out of that branch
and lower the _short threshold from >= 3 to >= 2 so the warning
fires for balanced rapid cycles too.
* fix(battery): make mScanning volatile (greptile follow-up on #57)
Greptile second-pass on #57 flagged that the volatile fix applied to
currentwait and scanpending was incomplete: mScanning has the same
shape — written inside synchronized(MeterScanner.this) in
scanRunnable, read outside any lock in stopScan() when called from
the timeout runnable. The JMM doesn't guarantee the timeout thread
sees mScanning = true, so stopScan(true) could skip scanStopper()
and reschedule a redundant scan. Make mScanning volatile so the
read in stopScan sees the latest value without expanding the lock
scope.
---------
Co-authored-by: Rob <rob@performanceinsights.ai>1 parent 7ac101d commit 9bfd44f
2 files changed
Lines changed: 26 additions & 23 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
616 | 616 | | |
617 | 617 | | |
618 | 618 | | |
619 | | - | |
620 | | - | |
621 | | - | |
622 | | - | |
623 | | - | |
624 | | - | |
625 | | - | |
626 | | - | |
627 | | - | |
628 | | - | |
629 | | - | |
630 | | - | |
631 | | - | |
632 | | - | |
633 | | - | |
634 | | - | |
635 | | - | |
636 | | - | |
| 619 | + | |
| 620 | + | |
| 621 | + | |
| 622 | + | |
| 623 | + | |
| 624 | + | |
| 625 | + | |
| 626 | + | |
| 627 | + | |
| 628 | + | |
| 629 | + | |
| 630 | + | |
| 631 | + | |
| 632 | + | |
| 633 | + | |
| 634 | + | |
| 635 | + | |
| 636 | + | |
| 637 | + | |
| 638 | + | |
| 639 | + | |
637 | 640 | | |
638 | 641 | | |
639 | 642 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
52 | 52 | | |
53 | 53 | | |
54 | 54 | | |
55 | | - | |
| 55 | + | |
56 | 56 | | |
57 | 57 | | |
58 | 58 | | |
| |||
199 | 199 | | |
200 | 200 | | |
201 | 201 | | |
202 | | - | |
| 202 | + | |
203 | 203 | | |
204 | 204 | | |
205 | 205 | | |
| |||
262 | 262 | | |
263 | 263 | | |
264 | 264 | | |
265 | | - | |
266 | | - | |
| 265 | + | |
| 266 | + | |
267 | 267 | | |
268 | 268 | | |
269 | 269 | | |
| |||
303 | 303 | | |
304 | 304 | | |
305 | 305 | | |
306 | | - | |
307 | 306 | | |
| 307 | + | |
308 | 308 | | |
309 | 309 | | |
310 | 310 | | |
| |||
0 commit comments