ZeroDivisionError on TUI

[adamchainz]

Bug Report

Current Behavior TUI crashes with a ZeroDivisionError when pressing "right arrow" after program has completed.

Input Code

Run memray run --live -c 'print(1)'. It completes shortly, and the TUI opens saying "Thread 1 of 0". Pressing the right arrow key to cycle between threads crashes with:

Traceback (most recent call last):
  File "/.../venv/bin/memray", line 8, in <module>
    sys.exit(main())
  File "/.../venv/lib/python3.9/site-packages/memray/commands/__init__.py", line 124, in main
    arg_values.entrypoint(arg_values, parser)
  File "/.../venv/lib/python3.9/site-packages/memray/commands/run.py", line 308, in run
    _run_child_process_and_attach(args)
  File "/.../venv/lib/python3.9/site-packages/memray/commands/run.py", line 117, in _run_child_process_and_attach
    raise error from None
  File "/.../venv/lib/python3.9/site-packages/memray/commands/run.py", line 114, in _run_child_process_and_attach
    LiveCommand().start_live_interface(port)
  File "/.../venv/lib/python3.9/site-packages/memray/commands/live.py", line 110, in start_live_interface
    tui.previous_thread()
  File "/.../venv/lib/python3.9/site-packages/memray/reporters/tui.py", line 371, in previous_thread
    self._thread_idx = (self._thread_idx - 1) % len(self._threads)
ZeroDivisionError: integer division or modulo by zero

Expected behavior/code no crash

Environment

• Python(s): 3.9

Possible Solution

n/a

Additional context/Screenshots n/a

[godlygeek]

Thanks for the great reproducer ❤️

The fix is simple enough - before we get our first sample from the tracked process, we don't know what threads exist, so we need to handle that case by just doing nothing if the next/prev thread button is pressed.

What's weird is that we're somehow not learning what threads exist(ed) even after the tracked process exits, so something more may be going wrong here... We should only be in that weird "before first sample" state for a few milliseconds, and certainly shouldn't stay in it once the tracked process has already completed...

[godlygeek]

Ah, OK. So this isn't just the state before the first sample, it's also the state when no memory has been allocated - and that's what your reproducer is hitting. We start the TUI before any samples have been collected, so we're in the state where we have no map of allocations to thread, and by the time we collect the next sample (a few milliseconds later) the process has allocated a bunch of memory, but also already freed everything that it allocated and exited, and so we still don't have any allocations to display, since at all times what the --live view shows is what has been allocated but not yet freed.