Excessive crashing while cropping

i’m trying to click through the crop settings, one dimension at a time, it keeps crashing on me, after a handful of clicks. any ideas?
version info:

Python version:  3.6.8 |Anaconda, Inc.| (default, Dec 30 2018, 01:22:34) 
[GCC 7.3.0]
Qt wrapper:  PyQt5
Qt version:  5.9.6
qtpy version:  1.7.0
Numpy version:  1.16.2
Scipy version:  1.2.1
OpenCV version:  3.4.2


Traceback (most recent call last):
  File "/home/wdf/anaconda3/lib/python3.6/site-packages/tracker/workers.py", line 371, in run
  File "/home/wdf/anaconda3/lib/python3.6/site-packages/tracker/workers.py", line 263, in parrallel_manager
    active_tracks, combined_inter_arrays = collect_results(active_workers, slices)
  File "/home/wdf/anaconda3/lib/python3.6/site-packages/tracker/workers.py", line 188, in collect_results
    combined_inter_arrays[key] = chunks_to_array((r[1][key] for r in results), slices)
  File "/home/wdf/anaconda3/lib/python3.6/site-packages/tracker/tools.py", line 226, in chunks_to_array
    stack = np.vstack((stack, int_stack))
  File "/home/wdf/anaconda3/lib/python3.6/site-packages/numpy/core/shape_base.py", line 283, in vstack
    return _nx.concatenate([atleast_2d(_m) for _m in tup], 0)
ValueError: all the input array dimensions except for the concatenation axis must match exactly
Aborted (core dumped)

Well that sucks. pass a -w 1 to only run it on one core:

tracker -w 1

I found the bug. The workers are telling the main process that they are done before actually putting the results in the queue.

tracker/workers.py L427

        # tell the queue that we are done

        # place the results in the result queue
        if cls.gui:
            RESULT_QUEUE.put((cls.worker, inter_arrays, local_tracks))

can you tell me the number of workers and the shape (width, height) of the video?

The video is 800x600 pix. I wasn’t specifying the number of workers. The laptop I was using it on is supposed to have a i5-2520M CPU which has two double threaded cores, so I guess tracker opens with four workers by default for me?

yes. Maybe the machine is running out of resources? I am trying to reproduce it.

it could be an Ubuntu issue. reminds me of a problem compiling exa on my last quad core machine. make -j 4 compiled fine but make -j would freeze it every time.

I managed to reproduce it by over specifying the number of workers. Looks like something is not right.

I found the bug. There was a race condition in there where workers could finish processing their chunk and get another chunk of the same frame before the correct worker got a piece. A simple join() in the worker process prevents this.