1

My TeamCity build is randomly failing with the following message:

[16:25:45][Step 1/2] [16:25:45] Build complete!
[16:25:45][Step 1/2] [16:25:45] Finished 'build' after 3.32 min
[16:25:45][Step 1/2] [16:25:45] Starting 'test'...
[16:25:48][Step 1/2] Assertion failed: 0, file src\uv-common.c, line 103
[16:25:48][Step 1/2] Process exited with code 3
[16:25:48][Step 1/2] Step Gulp (Command Line) failed

Some details:

  1. I'm using the command line runner: call npm install; call gulp ci
  2. The step in question is running NUnit on my compiled test binaries.
  3. I cannot reproduce the issue via the command line.

Environment info:

  • TeamCity v9.0.2 (latest at time of writing)
  • Node v10.36 (latest at time of writing)
  • Gulp v3.8.10 (latest at time of writing)
  • NUnit.Runners nuget package 2.6.4 (latest at time of writing)
Josh Kodroff
  • 27,301
  • 27
  • 95
  • 148

2 Answers2

2

This about says it all, right? 

Assertion failed: 0, file src\uv-common.c, line 103
Process exited with code 3

Someone has set an assertion for the sake of debugging. Line 103 includes that assertion, in fact. I would guess that zero here is the value in question that was tested.

 98 #define UV_ERR_NAME_GEN(name, _) case UV_ ## name: return #name; 
 99 const char* uv_err_name(int err) { 
100   switch (err) { 
101     UV_ERRNO_MAP(UV_ERR_NAME_GEN) 
102     default: 
103       assert(0); // <- Here's the assertion that failed
104       return NULL; 
105   } 
106 } 
107 #undef UV_ERR_NAME_GEN

There's a functioning line two higher than your assertion. It wants to trap an error as seen, mapping it into something known. That "default:" means that it's an unknown error, one the author doesn't know about. The assertion then is meant to die like this since he didn't know how best to deal with it.

So now, what is libuv? It's a networking library. It all depends upon what you were doing when the call to uv_err_name(something) was called. Could have been a getaddrinfo() call, for example. The underlying tcp stack is supposed to return recognizable error numbers. Obviously, your version didn't recognize what was returned from the tcp stack.

So, now that we reasonably understand the problem I'd strongly suggest updating the libuv libraries related to this. Repeat the test. If it fails again verify that you're connected to the Ethernet (something if you're on Wi-Fi that can be turned off).

Michael Blankenship
  • 1,639
  • 10
  • 16
  • At your project directory you could see what version(s) of libuv are embedded in your existing modules: findstr /S /I /C:"\"libuv\":" package.json – Michael Blankenship Mar 22 '15 at 22:35
  • Thanks for the detailed answer, but I was looking for something at a higher level of abstraction, as in "what's the actual problem?" at a gulp level or higher. – Josh Kodroff Mar 23 '15 at 15:10
  • The problem may not actually be in your code. You're relying upon the foundation of opensource code to be built well. If you read the comments in the libuv area you'll see that others have complained about this and similar errors. And the author of libuv is then addressing these issues with updated versions. My gut's telling me that the problem is in a DNS lookup step where it's trying to get an IP address from a hostname supplied, for example. A work-around might be to make an entry in your HOSTS file locally to cheat the DNS step. Presumably the host is github.com. – Michael Blankenship Mar 23 '15 at 23:50
2

As Michael pointed out, this is due to the libuv networking lib.

There is a lot of chances that your error comes from the EHOSTDOWN code that is not handled by the lib and make your process fail.

There is actually a few issues on either the joyent repo or the libuv one about this.

It seems that this commit have fixed it and is now live with the 0.12.1 version of Node.

Josh Kodroff
  • 27,301
  • 27
  • 95
  • 148
Preview
  • 35,317
  • 10
  • 92
  • 112