Node.js, Cygwin et Socket.io entrent dans un bar ... Node.js jette ENOBUFS et tout le monde meurt

Question

J'espère que quelqu'un ici peut m'aider, je ne suis pas du avoir beaucoup de chance de trouver cela par moi-même. Je suis en cours d'exécution node.js la version 0.3.1 sur Cygwin. Je suis l'aide de Connecter et d'une Douille.io. Il me semble avoir des problèmes aléatoires avec DNS ou quelque chose, je n'ai pas tout compris. Le résultat final est que j'ai le serveur est en cours d'exécution fine, mais quand un navigateur tente de se connecter à la première Requête HTTP œuvres, Socket.io se connecte, puis le serveur meurt (sortie ci-dessous).

Je ne pense pas que cela ait quelque chose à voir avec la requête HTTP, car le serveur reçoit beaucoup de données affichés, et il reçoit des demandes et de répondre jusqu'à ma connexion qui l'a tué. J'ai googlé autour de et la chose la plus proche que j'ai trouvé est DNS être réglée correctement. C'est un réseau de programme destiné à être exécuté que sur un réseau interne, donc j'ai mis l' nameserver x.x.x.x mon /etc/resolv.conf pour le DNS interne. J'ai aussi ajouté nameserver 8.8.8.8 de plus. Je ne suis pas sûr de ce qui reste à vérifier, mais vous serais reconnaissant de toute aide.

En 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

Nœud De Sortie:

    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)

MODIFIER

Je suis de la frappe d'un serveur LDAP à l'aide de http.createClient immédiatement après qu'un client se connecte à obtenir des informations, et qui semble être où est le problème qui est à l'origine ENOBUFS. J'ai édité la source d'inclure && errno != ENOBUFS qui empêche maintenant le serveur de mourir, mais maintenant la requête LDAP ne fonctionne pas. Je ne suis pas sûr de ce que le problème est que serait la cause de cela. Comme je l'ai dit c'est une seule application, j'ai donc mis les serveurs DNS en /etc/resolv.conf sur les serveurs DNS qui sont appliquées à la machine hôte. Pas si sûr que ce est une partie de la question?

EDIT 2

Voici une partie de la sortie de gdb --args ./node_g --debug ../myscript.js. Je ne sais pas si cela est lié à ENOBUFS, cependant, comme cela semble être le débrancher immédiatement après la connexion avec la Prise.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, j'ai creusé un peu, et après votre deuxième édition, j'ai trouvé ce bug sur la question de la liste.

Je ne prend pas en état de savoir si cela a été rencontré sous cygwin ou pas, mais l'erreur c'est de frapper mène à ce morceau de 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];
  }

De ce que je peux lire (avec mon rouillé C) il vous permet de convertir il va créer un nouveau uin16 tableau et d'écrire le contenu de la V8 chaîne, puis il va s'assurer que la conversion n'a pas écrit toutes les valeurs en dehors de la plage de 0 - 255, et c'est exactement ce qui ne parvient pas ici.

Je ne pouvais pas trouver quelque chose quant à savoir si c'est un V8 problème ou non.

Depuis que le code a été ajouté dans ce commit, la seule chose que je peux suggérer ici est d'essayer de tirer sur les arbres à partir d'un commit avant que le code a été ajouté. Depuis toutes les versions après qui ont le fracas de code.

Si cela fonctionne, je vous recommande de présenter un autre rapport de bug sur la question Node.js liste des problèmes, bien que j'ai fait faire plus tard ce jour-là.

Answer 2

Très difficile de répondre à celui-ci mais +1 pour la ligne d'objet.

Node.js est livré avec une suite de tests avec la construction principale, avez-vous exécuté cela? J'avais construit le noeud avec succès, mais comme j'avais omis d'utiliser OpenSSL, mes tests de socket Web échouaient. Installer / reconstruire corrigé. Les projets de test m'ont aidé à diagnostiquer le problème.

suggère de faire "make test" comme le décrit http://nodejs.org/#download .