Node.js, Cygwin and Socket.io enter the panel ... Node.js throws ENOBUFS and everyone dies

Question

I hope someone here can help me, I won’t be able to figure it out myself. I am running node.js version 0.3.1 on Cygwin. I use Connect and Socket.io. It seems that I have some random problems with DNS or something else, I did not quite understand this. The end result is that my server is working fine, but when the browser tries to connect to it, the initial HTTP request works, Socket.io connects, and then the server dies (output below).

I do not think this has anything to do with the HTTP request, because the server receives a lot of data sent to it, and it received requests and answered before my connection, which killed him. I searched googled, and the closest I found is the DNS set incorrectly. This is a network program designed to work only on the internal network, so I installed nameserver xxxx in my /etc/resolv.conf for internal DNS. In addition, I added nameserver 8.8.8.8 . I'm not sure what else to check, but would be grateful for any help.

In node.exe.stackdump

 Exception: STATUS_ACCESS_VIOLATION at eip=610C51B9 eax=00000000 ebx=00000001 ecx=00000000 edx=00000308 esi=00000000 edi=010FCCB0 ebp=010FCAEC esp=010FCAC4 program=\\?\E:\cygwin\usr\local\bin\node.exe, pid 3296, thread unknown (0xBEC) cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args 010FCAEC 610C51B9 (00000000, 00000000, 00000000, 00000000) 010FCBFC 610C5B55 (00000000, 00000000, 00000000, 00000000) 010FCCBC 610C693A (FFFFFFFF, FFFFFFFF, 750334F3, FFFFFFFE) 010FCD0C 61027CB2 (00000002, F4B994D5, 010FCE64, 00000002) 010FCD98 76306B59 (00000002, 010FCDD4, 763069A4, 00000002) End of stack trace 

Node Output:

  node.js:50 throw e; // process.nextTick error, or 'error' event on first tick ^ Error: ENOBUFS, No buffer space available at doConnect (net.js:642:19) at net.js:803:9 at dns.js:166:30 at IOWatcher.callback (dns.js:48:15) 

EDIT

I click on the LDAP server using http.createClient immediately after connecting the client to get the information, and it seems that the problem is what causes ENOBUFS. I edited the source to include && errno != ENOBUFS , which now prevents server death, however now the LDAP request does not work. I'm not sure the problem is that this could lead to this. Since I mentioned that this is the only internal application, so I install the DNS servers in /etc/resolv.conf on the DNS servers that apply to the host machine. Not sure if this is part of the problem?

EDIT 2

Here are derived from gdb --args ./node_g --debug ../myscript.js . I'm not sure if this is related to ENOBUFS, however, since it seems to shut down immediately after connecting to Socket.io

  [New thread 672.0x100] Error: dll starting at 0x76e30000 not found. Error: dll starting at 0x76250000 not found. Error: dll starting at 0x76e30000 not found. Error: dll starting at 0x76f50000 not found. [New thread 672.0xc90] [New thread 672.0x448] debugger listening on port 5858 [New thread 672.0xbf4] 14 Jan 18:48:57 - socket.io ready - accepting connections [New thread 672.0xed4] [New thread 672.0xd68] [New thread 672.0x1244] [New thread 672.0xf14] 14 Jan 18:49:02 - Initializing client with transport "websocket" assertion "b[1] == 0" failed: file "../src/node.cc", line 933, function: ssize_t node::DecodeWrite(char*, size_t, v8::Handle<v8::Value>, node::encoding) Program received signal SIGABRT, Aborted. 0x7724f861 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll (gdb) backtrace #0 0x7724f861 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll #1 0x7724f861 in ntdll!RtlUpdateClonedSRWLock () from /cygdrive/c/Windows/system32/ntdll.dll #2 0x75030816 in WaitForSingleObjectEx () from /cygdrive/c/Windows/syswow64/KernelBase.dll #3 0x0000035c in ?? () #4 0x00000000 in ?? () (gdb) 

Answer 1

OK, I did a little work, and after your second edit, I found this error in the list of problems.

I do not indicate whether this was encountered in cygwin or not, but the error it causes leads to this part of the code:

  uint16_t * twobytebuf = new uint16_t[buflen]; str->Write(twobytebuf, 0, buflen, String::HINT_MANY_WRITES_EXPECTED); for (size_t i = 0; i < buflen; i++) { unsigned char *b = reinterpret_cast<unsigned char*>(&twobytebuf[i]); assert(b[1] == 0); // this assertion fails buf[i] = b[0]; } 

From what I can read (with my rusty C), it will convert it, create a new uin16 array and write the contents of the V8 string to them, then it will ensure that the casting did not write any values ​​outside the range 0 - 255 , and that it is here that fails.

I could not find anything about whether this is a V8 problem or not.

Since the code was added to this commit , the only thing I can offer here is to try to pull the tree out of commit before adding the code . Since all versions after this have a bad code.

If this works, I would recommend you write another bug report in the Node.js release, although I did it later that day.

Answer 2

It is very difficult to answer this question, except for +1 for the topic.

Node.js comes with a test suite along with the main build, did you run this? I successfully built node, but due to the fact that I skipped OpenSSL, my tests in web juice did not run. Installation / recovery has been fixed. Test projects have helped me diagnose the problem.

suggests making a "make test" as http://nodejs.org/#download .