Node.js, Cygwin i Socket.io wchodzą do baru ... Node.js rzuca ENOBUFS i wszyscy umierają

Question

Mam nadzieję, że ktoś tu może mi pomóc, nie mam wielkiego szczęścia, że ​​sam to wymyślę. Używam node.js w wersji 0.3.1 na Cygwin. Używam Connect i Socket.io. Wydaje mi się, że mam pewne przypadkowe problemy z DNSem lub coś takiego, nie do końca zrozumiałem. Rezultatem jest to, że serwer działa dobrze, ale kiedy przeglądarka próbuje się z nim połączyć, początkowe żądanie HTTP działa, Socket.io łączy się, a następnie serwer umiera (dane wyjściowe poniżej).

Nie sądzę, że ma to coś wspólnego z żądaniem HTTP, ponieważ serwer dostaje dużo danych wysłanych do niego, a on odbierał żądania i odpowiadał aż do mojego połączenia, które je zabiło. Przeszukałem go i najbliższą rzeczą, którą znalazłem, jest nieprawidłowe ustawienie DNS. Jest to program sieciowy przeznaczony do pracy tylko w sieci wewnętrznej, dlatego ustawiłem nameserver x.x.x.x w moim /etc/resolv.conf na wewnętrzny DNS. Dodałem także dodatkowo nameserver 8.8.8.8. Nie jestem pewien, co jeszcze sprawdzić, ale byłbym wdzięczny za jakąkolwiek pomoc.

W 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 

Wyjście węzła:

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

mam trafienia serwer LDAP przy użyciu http.createClient natychmiast po klient łączy, aby uzyskać informacje, a to wydaje się gdzie jest problem, który powoduje ENOBUFS. Zmodyfikowałem źródło to include && errno != ENOBUFS, które obecnie uniemożliwia serwerowi wymieranie, jednak teraz żądanie LDAP nie działa. Nie jestem jednak pewien, na czym polega problem. Jak już wspomniałem, jest to aplikacja wewnętrzna, dlatego ustawiłem serwery DNS w /etc/resolv.conf na serwery DNS, które są stosowane na komputerze hosta. Nie jesteś pewien, czy to część problemu?

EDIT 2

Oto niektóre wyjście z gdb --args ./node_g --debug ../myscript.js. Nie jestem pewien, czy jest to związane z ENOBUFS jednak, jak się wydaje, do odłączania natychmiast po połączeniu z 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, trochę się wykopałem, a po drugiej edycji znalazłem this bug na liście problemów.

ja nie precyzuje, czy wystąpił pod Cygwin lub nie, ale ten błąd, że jest uderzanie prowadzi w dół do tego kawałka kodu:

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]; 
    } 

Z tego co czytałem (z moim zardzewiałym C) to się skonwertuje, utworzy nową tablicę uin16 i zapisze zawartość łańcucha V8 w swoich, wtedy zapewni, że casting nie zapisał żadnych wartości spoza zakresu 0 - 255, a to właśnie tutaj zawodzi.

Nie mogę znaleźć niczego, co dotyczy tego, czy jest to problem V8, czy nie.

Ponieważ kod został dodany w this commit, jedyne co mogę zasugerować tutaj, to spróbować wyciągnąć drzewo z zatwierdzenia przed dodaniem kodu. Ponieważ wszystkie kolejne wersje mają awaryjny kod.

Jeśli to zadziała, to polecam złożyć kolejny raport o błędzie na liście problemów Node.js, chociaż zrobiłem to później tego dnia.

Answer 2

Bardzo trudno odpowiedzieć na to jedno, ale +1 dla temacie.

Node.js jest dostarczany z pakietem testowym wraz z główną wersją, czy to uruchomiłeś? Z powodzeniem zbudowałem węzeł, ale ponieważ pominięto OpenSSL, moje testy gniazd internetowych zawodziły. Zainstaluj/odbuduj naprawiono. Projekty testowe pomogły mi zdiagnozować problem.

sugeruje wykonanie "make test" opisanego jako http://nodejs.org/#download.