google / syzkaller

When a new crash is discovered, it is put into the repro queue, and stays there until one of the VMs becomes free.

With physical devices serving as VMs, this may take up to an hour, when the fuzzing process is aborted and the VM is rebooted.

It might be good to abort fuzzing earlier when the repro queue is not empty.

We should already do this here:

Lines 403 to 405 in b438bd6

    
           if !stopPending && canRepro() { 
        
           	stopRequest = mgr.vmStop 
        
           }

Perhaps you have some VMs reserved for fuzzing?

No, I have explicitly commented out fuzzing_vms from the config before running the manager.

We should already do this here:

This specific problem appeared when the crash was discovered during corpus triaging. In that case, canRepro() was false.

pkg/repro: consider jobs in the repro queue when fuzzing