This was a failure in t.simple-interface.no-repo. (It happens in other places) That regression tries to run every bk command in an empty directory with a couple different generic command line arguments. It is trying to show that commands won’t fail because we didn’t hand bad command line arguments.

An assert(0) called during the cleanup routines after bk exits. In this case a routine at utils.c:rmdir_findprocs(). This routine ONLY runs in regressions and can’t happen in production. It reads /proc and sees if any bk processes are running in a deleted directory. That is strictly not allowed on Windows so we make sure Linux never does it so we don’t break Windows compatibility.

In this case, the process finds that it is running in a deleted directory.

What appears to be happening here is that ‘bk upgrade’ will spawn a process in the background that will talk to bk’s server to find the latest release and write that result in $HOME/.bk/latest-bkver. That background process occasionally takes long enough that the regression is finished and cleaning up before exiting and this causes the assert.

We need to tweak something to avoid this regression failure. One or more of the following:

Don’t spawn a background process in regressions

Don’t freak out if this command is the one running in a deleted directory

Have that upgrade process chdir($HOME) before running (Unfortunately $HOME is fake in regressions and that is the directory being deleted.)