9f92d1826e65df2b4c7790a8446cec54b5592258
Root cause: compute_dc_image/compute_rf_image chunked processing by a fixed 32-row count, sized for old small-format scans. A real v6 file with spf=2500 and up to ~7500 frames/angle needed ~6-7 GB for a single chunk's core buffers, on a 17 GB machine — pushing past available memory on every angle and aborting the process (not a clean MemoryError) when switching to a new angle piled more allocations on top. Chunk size is now computed from actual scan dimensions to hit a fixed ~128 MB budget instead of a fixed row count, cutting peak footprint by roughly 16-18x (verified against the real 532 GB / 17-angle dataset: ~400 MB peak, no crash). Also hardens QThread lifecycle handling, found while chasing this crash: - _on_compute_thread_finished/_on_load_thread_finished/ _on_preprocess_thread_finished now call wait() before dropping the last reference to a finished QThread, avoiding "QThread: Destroyed while thread is still running" aborts if the OS thread hasn't fully joined when finished() fires. - _start_compute/_load_file/_on_preprocess now claim their QThread immediately after the busy-guard check, before any call that can pump the Qt event loop (e.g. first QProgressDialog.show()), closing a reentrancy window where a second call could start a thread that the first call's own assignment would then clobber mid-run. - faulthandler is enabled at startup so any future native crash prints a real stack trace instead of a bare "Aborted". Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Description
No description provided
Languages
Python
91.6%
HTML
8.4%