3

I have a build running in TeamCity, with only one build step: launching a BAT file. TeamCity sometimes kills my build with a (double) keyboard interrupt, and I have no idea why. The output at the end of the build is like this:

Running build failed.
Error:
NUnit test failed (7).
Starting BuildFailureTarget: recover
Uninstalling service under test..Terminate batch job (Y/N)? 
^C
Process exited with code -1073741510

This build runs some integration tests via NUnit, after installing a Windows service, with a SQL database. If any of the tests fail, the build script (which uses FAKE, F#'s Make) runs some cleanup—uninstalls the service, tears down the database. It's the same cleanup code that runs when the build passes, only the target name is different (recover). It seems that TeamCity only kills the build when some tests have failed. I should note that the message "Uninstalling service under test" is from a subprocess which is running the uninstaller. This still happens even if we turn off several failure conditions such that the build (spuriously) passes after several tests fail (we are not using Java, so we assume that one is irrelevant):

even with build failure conditions turned off

I can't figure out why TeamCity is killing my build before it is done. How do I figure out what would cause TeamCity to issue this interrupt?

Keith Pinson
  • 7,835
  • 7
  • 61
  • 104
  • 1
    I'd suggest you to check buildAgent/logs/teamcity-agent.log and buildAgent/logs/teamcity-build.log files for a clue. At the end of the build, Teamcity kills all subprocesses started by the build to avoid garbage in memory. If your build process does not wait for subprocess to finish, this may be a problem. – KIR Jun 12 '19 at 18:30

1 Answers1

1

It seems that TeamCity does this if it detects dangling processes (not sure how to be more precise about that). What we had happening was that an exception was being thrown by a third-party library while we were running a subprocess, before the code that stopped that process. The exception was handled, and the cleanup that got triggered by the exception would have resulted in the process getting shut down anyway (through another means), but before that cleanup was finished, TeamCity was killing our build: which ironically meant that the process never did get shut down.

Our solution was to catch the exception and ensure the first shutdown code got called before failing. Ultimately we were not able from a TeamCity side to get more clarity on what was happening: we found the bug by careful analysis of our code. However it seems that this happens when standard cleanup logic for subprocesses fails.

Keith Pinson
  • 7,835
  • 7
  • 61
  • 104