diff options
| author | blasty <blasty@local> | 2026-08-06 23:41:11 +0200 |
|---|---|---|
| committer | blasty <blasty@local> | 2026-08-06 23:41:11 +0200 |
| commit | 77db4042fbc913cedd44e63d8eced50b5702794f (patch) | |
| tree | 5e3760994dead3ce892b6d8c1b1e3874d3c8ecf9 /experiments/fibonacci.elf | |
| parent | tests: wait for the thing, don't sleep and hope (diff) | |
| download | ida-tui-77db4042fbc913cedd44e63d8eced50b5702794f.tar.gz ida-tui-77db4042fbc913cedd44e63d8eced50b5702794f.tar.xz ida-tui-77db4042fbc913cedd44e63d8eced50b5702794f.zip | |
tests: deterministic fixtures, and a correction
all_funcs() forced a full load of the function index only when it was EMPTY, so
a partially streamed index -- non-empty but incomplete, which is exactly the
state during boot and after any bump_items() -- came back truncated. Every
fixture picked through find_func/biggest therefore depended on how far streaming
had got by the time a scenario asked.
That is the graph_minimap flake: on an unlucky run find_func(size > 0x300)
picked a much larger function than usual, whose graph never finished inside the
scenario's own 60s wait. Three failures and 65 seconds, one run in several, with
no code change to blame. Three consecutive clean runs at 1.7s since.
CORRECTION to f898350, which said a range cache for function_of 'broke
graph_minimap'. It did not. The failure happened in the run after I added the
cache and I attributed it without checking; it recurred with the cache long
gone. The cache is still not here, but for the honest reason: with the resync
loop fixed, function_of is down to 340 calls and 1.4s across the whole suite,
so caching it is not worth the invalidation surface.
Suite 195.7s -> 138.4s, 732 checks.
Diffstat (limited to 'experiments/fibonacci.elf')
0 files changed, 0 insertions, 0 deletions
