Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | evented I/O for v8 javascript edit |
-
Just tried building node.js @ 5b1a535 and had this problem:
Let me know if there's anything I can try to help troubleshoot.
Looks like an awesome project by the way :)
— ben_h
Comments
-
The helloworld.js works fine. But other project like node_chat or benchmarks/static_http_server.js
get this error: Segmentation fault: 11 (core dumped)$>uname -a FreeBSD 8.0-RELEASE <a href="/ry/node/issues/#issue/0" class="internal">#0</a>: Sat Nov 21 15:48:17 UTC 2009 root@almeida.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 $>node -v 0.1.20 $>gdb -c node.core This GDB was configured as "i386-marcel-freebsd". Core was generated by `node'. Program terminated with signal 11, Segmentation fault. <a href="/ry/node/issues/#issue/0" class="internal">#0</a> 0x080c18cf in ?? ()Comments
UnderCooled
Fri Dec 04 22:50:03 -0800 2009
| link
gdb trace on node_debug/example.js
UnderCooled
Sat Dec 05 08:47:27 -0800 2009
| link
When running helloworld.js i tried to reload the page then get Segmentation fault too.
I think the problem may relate to this issue on evcom:
Can you try to debug it a bit? Build the node_g executable with symbols
./configure --debug makeThen send me a stacktrace
I've encountered the same problem too:
root@soulfury:~# uname -a FreeBSD chaosbuilder.simoncpu.com 7.1-RELEASE-p8 FreeBSD 7.1-RELEASE-p8 #0: Thu Oct 8 19:24:29 PHT 2009 admin@soulfury:/usr/obj/usr/src/sys/INARA i386 root@soulfury:~# node_g -v 0.1.21 (debug) root@soulfury:~# gdb node_g node_g.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Core was generated by `node_g'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libexecinfo.so.1...done. Loaded symbols for /usr/local/lib/libexecinfo.so.1 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x081627bc in v8::internal::HeapObject::map_word (this=0xa286a41) at objects-inl.h:1022 1022 return MapWord(reinterpret_cast(READ_FIELD(this, kMapOffset))); [New Thread 0x2878d200 (LWP 100080)] [New Thread 0x28701100 (LWP 100092)] (gdb) quit
UnderCooled
Fri Dec 18 19:40:33 -0800 2009
| link
the problem still exists in v1.22.
<a href="/ry/node/issues/#issue/0" class="internal">#0</a> 0x081634fc in v8::internal::HeapObject::map_word (this=0xa2aa001) at objects-inl.h:1022 1022 return MapWord(reinterpret_cast<uintptr_t>(READ_FIELD(this, kMapOffset))); [New Thread 28992ec0 (LWP 100128)] [New Thread 28993140 (LWP 100083)] [New Thread 28901140 (LWP 100101)] (gdb) quit -
I've noticed that the testing framework that node uses is severly lacking documentation, and I feel that in any solid web platform should have good documentation on how to test it.
Comments
I'm working on this in the fork over at: http://github.com/Miksago/node/
visionmedia
Tue Dec 15 18:18:11 -0800 2009
| link
Id say we should use JSpec, just gotta wait till 3.0 for true async support
Well, either way, the testing framework needs documentation.
JSpec as a syntax for testing does look nice, but it kind of abstracts too far away from javascript, it's good to remember which context we're in. Not only that, but how might you be running the tests you write, I'm guessing you'd be running them on the server, over an ssh connection, which is where something more like the ruby testing framework style thing would be more useful.
JSpec seems to fall somewhere between CI and Manual testing.
Actually, I might have a crack at writing a bit of a simple test runner, I'm not sure how it'll go though.
visionmedia
Wed Dec 16 08:03:42 -0800 2009
| link
You dont have to use the grammar.. You can run it in several browsers concurrently using the ruby server and report back to the terminal, or using Rhino via Terminal, or Node via Terminal, or just in one browser at a time via the file:// protocol, its very flexible. Check out my Express project it uses JSpec
hmm.. okay.
Although, what about testing things that don't need browsers?
visionmedia
Wed Dec 16 20:21:07 -0800 2009
| link
then you just run it with Node or Rhino, Express is for server-side Node.js, not a browser
-
Node rev: e801f42
I'm getting a segfault in an app that makes few dozen http requests + serving few requests locally http://github.com/ncr/flickr_spy/commit/a1528373b0e454cfb9e2a640661f0502b730fb51
The segfault happens consistently when I connect 2 clients to my server (responses are streamed and take about 1-2 mins), when I connect only 1 client it works ok.
Here's the stacktrace fragment from node_g:
# # Fatal error in /Users/ncr/dev/node/deps/v8/src/objects-inl.h, line 1585 # CHECK(object->IsProxy()) failed # ==== Stack trace ============================================ Security context: 0x649205 #0# 2: flushMessageQueue(this=0x649281 #1#,connection=0x78bde1 >#2#,queue=0x78ee9d #3#) 3: /* anonymous */(this=0x78eee9 >#4#) 7: flush(this=0x78eee9 >#4#) 8: sendBody(this=0x78eee9 >#4#,chunk=0x1a69155 ,encoding=0x65a12d ) 9: arguments adaptor frame: 1->2 10: /* anonymous */(this=0x78bdc5 >#5#,data=0x1a61219 #6#) 14: /* anonymous */(this=0x649281 #1#,user_ids=0x1a60999 #7#) 15: /* anonymous */(this=0x1814121 >#8#,data=0x1a5f0c9 >#9#) 16: arguments adaptor frame: 2->1 20: _respond(this=0x1814121 >#8#,type=0x65fbed ,data=0x1a5f0c9 >#9#,response=0x18140a9 >#10#) 21: /* anonymous */(this=0x18140a9 >#10#) 25: /* anonymous */(this=0x18006bd >#11#) 29: /* anonymous */(this=0x649281 #1#) 30: /* anonymous */(this=0x649281 #1#)How can I help more (not being c coder for 10 years now)?
Comments
-
0 votes
res.finish() doesn't properly closes the connection when streaming.
1 comment Created 3 days ago by chakritServer script is:
var http = require('http'); var server = http.createServer(function(req, res) { res.sendHeader(200, {'Content-Type': 'text/plain'}); var counter = 5; setTimeout(function() { if (counter--) { res.sendBody("HELLO....\n"); setTimeout(arguments.callee, 1000); } else { // should closes the connection res.finish(); } }, 1000); }); server.listen(8000); // should fetches 50 bytes of HELLOsExecuting
wget 0.0.0.0:8000should fetch 50 bytes of HELLOs from the server in approximately 5 seconds and then the connection should be closed.Comments
It doesn't look like the connection is closing ever event when not streaming. Here's an example:
require('http') .createServer(function(request, response){ response.sendHeader(200, {'Content-Type' : 'text/plain'}); response.sendBody("zoom"); response.finish(); }).listen(8000);When I run the following ab, eveything goes swimmingly:
ab -c 50 -n 100000 -k http://127.0.0.1:8000/
But when I don't keep the connections alive with:
ab -c 50 -n 100000 http://127.0.0.1:8000/it dies after about 16.5K requests every time. I'm sorry I'm not able to write a test for this one :( I'm not sure where to look yet :(
-
Although WAF was recently upgraded, bin/node-waf still reports version 1.5.9. This produces an error when the file is used to build some external module:
$ node-waf configure build Error: Version mismatch: waf 1.5.9 <> wafadmin 1.5.10 (wafdir /usr/local/bin/../lib/node)Comments
-
I noticed a bug introduced in ry@3b8e477
whereby require("../foo") fails to work. The problem is that paths
like "foo/bar/../baz" get turned into "foobaz" instead of "foo/baz".Discussion thread here: http://groups.google.com/group/nodejs/browse_thread/thread/34779f8c10098c5e
Isaac Schlueter kindly took my original fix (jasondavies@79efd86) and rewrote it to avoid using regexps and added tests: http://gist.github.com/260278
Comments
I get the same error here, 10.6.2.
Yep, I'm on 10.6.2 as well. A couple more details:
⚡ uname -a
Darwin hat.local 10.2.0 Darwin Kernel Version 10.2.0: Tue Nov 3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386
⚡ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
If you try to build V8 by itself:
Do you get the same error?
Or more easily:
Just gave that a go:
so it appears to me that this is a bug in v8. would you like to open an issue with them?
http://code.google.com/p/v8/issues/entry
em, wait a moment -
the error you got the second time is not the same as the first. Can you please try with a fresh checkout of v8?
Yep, it's a v8 problem:
I'll file a bug report with them, cheers.
FYI: http://code.google.com/p/v8/issues/detail?id=544
Hey guys, I was having the same issue, but I was able to successfully build v8 with the following options:
Odd. I'm running 10.6.2, one a branded new MBP, and node is compiling and installing fine from HEAD.