aboutsummaryrefslogtreecommitdiffstats
path: root/plan
diff options
context:
space:
mode:
authorblasty <blasty@local>2026-08-07 14:32:56 +0200
committerblasty <blasty@local>2026-08-07 14:32:56 +0200
commit21971d0a9ce9b8a2fb1db2ec67303696cea9cbbb (patch)
tree7122697940630116eae1b7e75756b68292cfe9b9 /plan
parentcodemode: three defects the A/B benchmark found in the decompiler path (diff)
downloadida-tui-21971d0a9ce9b8a2fb1db2ec67303696cea9cbbb.tar.gz
ida-tui-21971d0a9ce9b8a2fb1db2ec67303696cea9cbbb.tar.xz
ida-tui-21971d0a9ce9b8a2fb1db2ec67303696cea9cbbb.zip
tests: blob_ui 39.8s -> 4.1s, and a fatal it was hiding
Three separate wastes, all of the same family: waiting on a guess instead of a signal, and paying for work that never had to be repeated. 1. The 64KB blob was built with os.urandom into a fresh TemporaryDirectory on every run. New bytes at a new path means the pristine-database cache can never apply, so full auto-analysis of 64KB of AArch64-decoded noise was paid every single run. It is now built from a seeded PRNG at a stable path (tests/.synthetic/, gitignored) and staged through the existing cache. Determinism is also a correctness fix: whether 64KB of chance bytes contains something IDA reads as a function is luck, and this suite asserts "and really has no functions". 2. `wait(lambda: lst.model is not old, ..., 30)` after commenting. The perf work made an item edit KEEP the listing's walk and re-render in place, so the model object is never replaced and this waited out its full 30s timeout on every run -- and then "commenting leaves the view where it was" passed vacuously, because nothing had happened at all. A test that burns 30s to check nothing is worse than no test. 3. Two `pause(2.0)`/`pause(2.5)` after a carve, replaced with settle() on a real condition. The second one deliberately has NO predicate: that spot is random data, so the carve may legitimately produce nothing, and "the row became code" would never hold -- gating on it cost another 30s timeout. What that check is about is the VIEW not moving, so the gate is "the app finished reacting". Fixing (1) exposed a real bug in the client, fixed here too: reopening a database that already exists while passing loader switches is FATAL in IDA -- FATAL ERROR: Switch '-b400' can be used only when loading a new file which kills the worker before it can report anything. Loader switches describe an IMPORT and are recorded in the database they produce, so they are now sent only when there is an import to describe. This was never reachable from the old suite (a fresh random blob never had a database to reopen), but it is reachable by any user who opens a raw blob with --ida-args twice. 30 passed, 0 failed.
Diffstat (limited to 'plan')
0 files changed, 0 insertions, 0 deletions