QBS has ASSERTION from !m_availableJobs.isEmpty()

Custom Scanner {} that take to long to execute (over 1000ms) will cause an assertion. When the scanner's execution is longer than 1000ms the script engine times out, and processes events on the executor thread. This will cause recursive calls inside of Executor::onFinished(). I believe that these recursive calls are causing the issue.

The recursive calls causes Executer::scheduleJobs() schedule to many jobs. When a job is finished, it causes Exectuor::finishedJob() to be called. Executor::finishedJob() adds the finished job to m_availableJobs(). Then the executor schedule the available job(s). It starts running the a new job, if that job has a scanner that takes to long (> 1000ms) then the javascript engine signals a processEvents(), causing the recursive call to finishedJob(). At this point the first job hasn't be removed from the m_availableJobs(). When finishedJob is called again, the schedule thinks there's two jobs available instead of 1. This okay until, the recursive calls unwind and run out of jobs because they were over scheduled.

Work arounds:
Run QBS with -j 1 option. This prevents the assertion

Build QBS from source and comment out setProcessEventsInterval(1000); inside of the constructor of the ScriptEngine (inside of scriptengine.cpp). This will prevent the recursive calling. This will break the cancelation mechanism.

Ways to reproduce it:
Create a scanner in a module that takes more than 1000ms to execute. Set the job count to something high (-j 10).