[Windows] Disk offload crashes with access violation after DiskMap.flush_files() (apparent use-after-free)

[zhouxixiong4]

Environment

• OS: Windows 11 (x64)
• GPU: RTX 4060 Laptop 8 GB (driver 610.62)
• Python 3.12.10, torch 2.11.0+cu128, safetensors 0.8.0, bitsandbytes 0.50.0
• DiffSynth-Studio: current main, installed via pip install -e ".[quant]" (2026-08-03)

Reproduction

Run the official low-VRAM example examples/minimax_h3/model_inference_low_vram/MiniMax-H3-NF4-FL2VA.py on Windows (disk-offload vram_config with offload_device="disk").

The pipeline loads fine and prompt encoding starts, then the process dies with a hard native crash (no Python exception) while onloading the text encoder layers:

Windows fatal exception: access violation

Current thread 0x00017240 (most recent call first):
  File "torch\storage.py", line 471 in __getitem__
  File "diffsynth\core\vram\disk_map.py", line 62 in __getitem__
  File "diffsynth\core\vram\layers.py", line 496 in _load_from_disk
  File "diffsynth\core\vram\layers.py", line 520 in onload
  File "diffsynth\diffusion\base_pipeline.py", line 180 in load_models_to_device
  File "diffsynth\pipelines\minimax_h3_audio_video.py", line 382 in process

Analysis

DiskMap.__getitem__ calls flush_files() once num_params > buffer_size (default 1e9), which drops the open safe_open handles and re-opens them. Tensors previously returned by get_tensor may still reference the old mmap, so the next access after a flush is a use-after-free. On Windows this surfaces as an access violation inside torch.storage.__getitem__ instead of a catchable Python error.

Workaround

Setting DIFFSYNTH_DISK_MAP_BUFFER_SIZE=1000000000000 (effectively disabling the periodic flush) avoids the crash entirely — a full 50-step MiniMax-H3 generation then completes successfully.

Maybe flush_files() should not invalidate handles while tensors fetched from them can still be alive, or get_tensor results should be fully detached from the mmap before any flush can happen.