00:05:34  <txdv>why does the recv_callback get called with nread = 0?
00:06:04  <bnoordhuis>txdv: to give back the buffer
00:06:51  <txdv>this means that it doesn't need the buffer anymore and i can delete it?
00:07:02  <txdv>iif nread == 0?
00:07:10  <bnoordhuis>txdv: yes
00:07:37  <txdv>oO
00:08:07  <txdv>either you are lying, I have detected a memory leak or i need to update
00:08:09  <txdv>my libuv
00:10:00  <bnoordhuis>txdv: i always lie
00:10:18  <txdv>its not called lying when you believe in it
00:14:24  <bnoordhuis>piscisaureus__: still around?
00:18:51  <CIA-111>node: Ben Noordhuis isolates2 * r59faab4 / vcbuild.bat : Make msbuild run in parallel. - http://git.io/1-1B0w
00:18:51  <CIA-111>node: Ben Noordhuis isolates2 * r2afd20b / (5 files in 4 dirs): uv: upgrade to 85f6b79 - http://git.io/cXRClw
00:18:53  <CIA-111>node: Ben Noordhuis isolates2 * r9143b43 / (src/node_isolate.h src/ngx-queue.h): Include ngx-queue.h, fix Windows build. - http://git.io/aRrjgQ
00:19:49  <bnoordhuis>ryah: isolates2 compiles on windows now (but doesn't link for me, stupid "LNK1104: cannot open file 'z.obj'" error)
00:20:00  <bnoordhuis>anyway, i concede defeat at the hands of windows for today
00:24:06  <piscisaureus__>bnoordhuis: sup?
00:24:31  <bnoordhuis>piscisaureus__: scroll up two lines, why do i get that weird linker error?
00:25:13  <piscisaureus__>bnoordhuis: zlib not compiled probably?
00:25:38  <bnoordhuis>piscisaureus__: possible... shouldn't that happen automagically?
00:25:49  <piscisaureus__>I don't know, it works for me
00:26:09  <piscisaureus__>can you search your tree for z.lib or z.obj or libz.lib?
00:27:05  <bnoordhuis>piscisaureus__: missing, so that's probably it
00:27:11  <piscisaureus__>hmm well
00:27:17  <piscisaureus__>I'm looking up the filename
00:27:28  <piscisaureus__>should be zlib.lib
00:27:53  <bnoordhuis>./Debug/lib/zlib.lib
00:29:55  <piscisaureus__>bnoordhuis: ah it happens when linking zlib I thing
00:30:06  <piscisaureus__>'link_settings': {
00:30:07  <piscisaureus__> 'libraries': [
00:30:07  <piscisaureus__> '-lz',
00:30:07  <piscisaureus__> ],
00:30:07  <piscisaureus__> },
00:30:10  <piscisaureus__>in zlib.gyp
00:30:19  <piscisaureus__>I wonder why that doesn't cause any problems for me
00:30:23  * travis-cijoined
00:30:24  <travis-ci>[travis-ci] joyent/node#157 (isolates2 - 9143b43 : Ben Noordhuis): The build is still failing.
00:30:24  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b319699...9143b43
00:30:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/456588
00:30:24  * travis-cipart
00:30:41  <bnoordhuis>odd, i'm running vcbuild.bat from the vs2010 terminal
00:32:11  <piscisaureus__>bnoordhuis: maybe somhow use_system_zlib becomes 1
00:32:21  <piscisaureus__>or, whatever, anything other than 0
00:33:33  <bnoordhuis>nope, even when i unconditionally compile the bundled zlib, it still happens
00:35:45  <bnoordhuis>gah, it's the libraries:[-'lz'] in config.gypi
00:37:34  <piscisaureus__>I don't have that file
00:37:38  <piscisaureus__>are you on latest master?
00:37:45  <bnoordhuis>latest isolates2 even
00:37:50  <bnoordhuis>options.gypi's been renamed
00:40:59  <ryah>gr.. i need real intwrnwt:(((
00:41:10  <ryah>internet even
00:41:24  <CIA-111>libuv: Ben Noordhuis master * r0db56ea / src/win/thread.c : windows: implement uv_thread_self() - http://git.io/L9ReAA
00:41:53  <ryah>bnoordhuis go ahead and mege it
00:42:41  <bnoordhuis>aye aye, sir
00:42:55  <ryah>i want to keep stuff moving
00:43:01  * travis-cijoined
00:43:01  <travis-ci>[travis-ci] joyent/libuv#17 (master - 0db56ea : Ben Noordhuis): The build is still failing.
00:43:01  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/85f6b79...0db56ea
00:43:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/456656
00:43:01  * travis-cipart
00:43:21  * mralephquit (Quit: Leaving.)
00:43:41  <ryah>i might have found a problem in node_http_parser
00:44:03  * mikeal1quit (Quit: Leaving.)
00:44:04  <bnoordhuis>what is it?
00:44:46  <ryah>do yiu meed to parser->Flush() after http_parser_execute()?
00:45:10  * TooTallNatequit (Quit: Leaving...)
00:45:16  <CIA-111>node: Ben Noordhuis isolates2 * r5427311 / deps/uv/src/win/thread.c : uv: upgrade to 0db56ea - http://git.io/JMg7rQ
00:46:13  <bnoordhuis>ryah: not always, i think (off the top of my head)
00:47:16  <bnoordhuis>Flush() is for when the headers are too big to fit in the headers/fields array
00:47:19  <ryah>im worried about a packet with partial headers then the next packet not coming dor a long time after
00:47:59  <ryah>the pointers in StrinPtr will be dead
00:48:16  <bnoordhuis>if the buffer is recycled.... plausible
00:49:47  <ryah>lets get mjr_ to try a patch with flush. im going to cqfe for imternet. br
00:49:56  <ryah>b
00:51:52  <mjr_>I'm suspicious about the "long time after" behavior, unless time is measured in how many other IO events you handle before you get the next read.
00:53:32  <bnoordhuis>"long time" in this case means "long enough for the gc to reclaim the buffer" (which is variable)
00:53:37  <mjr_>When we are busy, which is when this problem happens most, we might handle thousands of other IOs between first partial read of the headers and the final read.
00:53:48  <mjr_>But it all happens within a second or so.
00:53:57  <bnoordhuis>otoh, that patch you tried should've eliminated that possibility
00:54:04  <bnoordhuis>curious bug
00:54:22  <mjr_>Yeah, I've always wondered about the buffer lifecycle thing. Never quite convinced myself of how it works.
00:55:15  * piscisaureus__quit (Ping timeout: 240 seconds)
00:56:39  * travis-cijoined
00:56:39  <travis-ci>[travis-ci] joyent/node#158 (isolates2 - 5427311 : Ben Noordhuis): The build is still failing.
00:56:39  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/9143b43...5427311
00:56:39  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/456662
00:56:39  * travis-cipart
00:56:44  * AvianFluquit (Quit: Leaving)
00:59:23  <CIA-111>node: Ben Noordhuis master * r0c3b357 / (43 files in 11 dirs): Merge branch 'isolates2' (+32 more commits...) - http://git.io/yHfbXA
01:03:19  * mikealjoined
01:04:42  * mikealquit (Client Quit)
01:09:03  <ryah>so a fd becomes readable - epoll tells libuv about it
01:09:26  <ryah>libuv asks node for a buffer - which node uses its buffer pool
01:09:40  <ryah>node gives it back to libuv who reads data into it - passes it back to node
01:09:46  <ryah>node runs the http parser over it
01:10:02  <ryah>if that packet, say, only contained the first part of the headers
01:10:14  <ryah>node is storing pointers to that buffer in its memory
01:10:29  <ryah>the buffer is part of a pool - so it's unlikely that it would be reclaimed by GC
01:10:34  <ryah>unless it was at the end of a pool
01:10:47  * travis-cijoined
01:10:47  <travis-ci>[travis-ci] joyent/node#159 (master - 0c3b357 : Ben Noordhuis): The build was broken.
01:10:47  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/b7c05e1...0c3b357
01:10:47  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/456688
01:10:47  * travis-cipart
01:10:57  <ryah>and GC happened in between the first packet and the second
01:11:26  <ryah>seems like a very rare situation - but i think it's imaginable
01:12:26  <mjr_>If you consider how many successful requests we process before this happens, I think you can accurately describe this situation as "rare".
01:12:58  <ryah>https://gist.github.com/1530919 <-- this is my suggestion
01:13:05  <mjr_>Except right now, this rare thing happens multiple times per hour. :)
01:13:42  <ryah>hm - but let's think about this a bit before
01:17:21  <mjr_>I'm going out for a while, but if you get any more insights, I'll be working again in a few hours.
01:17:41  <mjr_>Feel free to use that machine for whatever you like if it helps with this issue.
01:20:48  <ryah>that patch breaks the test so i need to figure that out first :)
01:23:28  * mikealjoined
01:32:18  * mikealquit (Quit: Leaving.)
01:34:05  * bnoordhuissigns off for the day
01:35:55  * mmaleckijoined
01:36:01  * mmalecki_quit (Quit: leaving)
01:38:01  * mikealjoined
01:38:18  * bnoordhuisquit (Ping timeout: 248 seconds)
01:39:17  * mikealquit (Client Quit)
01:54:02  * mikealjoined
01:54:43  * mikealquit (Client Quit)
01:55:33  * mikealjoined
01:57:21  * mikealquit (Client Quit)
02:26:51  * mmaleckiquit (Quit: leaving)
02:27:12  * mmaleckijoined
02:40:43  * ericktquit (Ping timeout: 252 seconds)
02:45:06  <ryah>grr
02:45:25  <ryah>really wish i could reproduce this parser problem
04:28:59  * isaacsjoined
05:10:06  * bradleymeckjoined
05:19:41  <mjr_>yes, me too.
05:49:15  * bradleymeckquit (Ping timeout: 240 seconds)
06:20:42  * mmaleckiquit (Read error: Operation timed out)
06:29:58  <DrPizza>if you have libs listed with the from "-l<libname>" e.g. "-lz", gyp tries to convert them to something more amenable to VC++
06:30:03  <DrPizza>it does not always succeed
06:30:08  <DrPizza>possibly it does not even often succed
06:52:36  * TooTallNatejoined
06:53:14  * TooTallNatequit (Client Quit)
08:25:01  * mjr_quit (Read error: Connection reset by peer)
08:25:17  * mjr_joined
08:44:39  * ericktjoined
09:20:42  * ericktquit (Quit: erickt)
09:23:33  * isaacsquit (Quit: isaacs)
09:32:06  * eddybjoined
09:32:13  <eddyb>guys, we're having some trouble
09:32:21  <eddyb>I hope some of you are around
09:32:27  <eddyb>Error: Unable to load shared library elm.node
09:32:35  <eddyb>from require('elm.node')
09:32:51  <eddyb>that module was built using a pretty standard wscript
10:02:39  * mmaleckijoined
10:11:52  * einarosjoined
10:30:39  <eddyb>so, node HEAD
10:30:54  <eddyb>installed node-waf and wafadmin manually
10:30:57  <eddyb>built https://github.com/shinuza/node-cc-module-boilerplate
10:31:07  <eddyb>node -e 'require("./build/Release/hello_node.node")'
10:31:14  <eddyb>Segmentation fault
10:54:20  * piscisaureus__joined
10:54:38  * mralephjoined
10:54:42  * piscisaureus__changed nick to piscisaureus_
11:07:13  <eddyb>here's the backtrace for that segfault
11:07:15  <eddyb>http://pastebin.com/RCex1h2g
11:28:02  <eddyb>ignore me
11:28:06  <eddyb>build system fail
11:28:20  <eddyb>apparently 0.6.6 is what I want, not git HEAD
11:28:22  * eddybpart ("Konversation terminated!")
11:47:48  * AndreasMadsenjoined
11:48:40  <AndreasMadsen>core team: it get this error when I try to compile node from master
11:48:41  <AndreasMadsen>NameError: name 'node_use_isolates' is not defined while evaluating condition 'node_use_isolates=="true"' in /Users/Andreas/GitHub/node/node.gyp while trying to load /Users/Andreas/GitHub/node/node.gyp
11:51:26  <AndreasMadsen>Oh i need to reconfigure :)
12:07:25  * AndreasMadsenquit (Remote host closed the connection)
12:33:22  * AndreasMadsenjoined
12:34:23  * bnoordhuisjoined
12:35:02  * AndreasMadsenquit (Client Quit)
12:46:58  * mralephquit (Quit: Leaving.)
13:22:54  * paddybyersjoined
13:36:52  <CIA-111>node: Jeremy Martin v0.6 * r8c3a757 / doc/api/http.markdown : docs: tiny typo in http.markdown - http://git.io/C-2A4w
13:36:59  <indutny>ryah: hi
13:37:08  <indutny>ryah: v8 patch?
13:37:35  <bnoordhuis>indutny: that's a dirty word
13:37:51  <indutny>bnoordhuis: going to wash my mouth
13:37:55  <bnoordhuis>good :)
13:38:04  <indutny>bnoordhuis: thanks
13:38:18  <indutny>TheJH just told me that I'm working on a v8 patch for fixing DoS issue
13:38:19  <bnoordhuis>is this about that hash collision thing?
13:38:23  <bnoordhuis>right, it is
13:38:26  <indutny>yep
13:38:33  <indutny>but I just heard that I'm working on it
13:38:41  <bnoordhuis>hah, you are?
13:39:05  <indutny>nope :D
13:39:07  <indutny>but I can
13:39:09  <indutny>probably
13:39:18  <einaros>it's absurd if the v8 team doesn't deal with this
13:39:26  <indutny>I'm not in v8 team
13:39:30  <einaros>I know
13:39:51  <indutny>I think that's not a priority for them
13:39:57  <indutny>but I may be wrong
13:40:22  <einaros>from what I heard, they said "something something already running in the browser"
13:40:22  <bnoordhuis>i suppose we could land an out-of-tree patch for now
13:40:52  <indutny>bnoordhuis: heh, I need to take a look at the problem first
13:41:04  <indutny>out-of-tree patch is ok, agreed
13:41:38  <einaros>quickfix, randomize the hash seed in objects.cc and preparse-data.h
13:41:50  <einaros>proper v8-fix: crit-bit trees
13:43:14  <indutny>einaros: do you think crit-bit trees will have same performrance?
13:43:22  <indutny>performance
13:44:29  * travis-cijoined
13:44:29  <travis-ci>[travis-ci] joyent/node#160 (v0.6 - 8c3a757 : Jeremy Martin): The build passed.
13:44:29  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/448c5e0...8c3a757
13:44:29  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/458078
13:44:29  * travis-cipart
13:45:25  <einaros>doubt it
13:45:41  <einaros>O(log n) best case from what little I've seen
13:46:00  <indutny>einaros: hm... I think v8 team won't accept it though
13:46:14  <einaros>but I believe I saw someone recommending a combination of hashes and such trees, which would make it O(1) best case and O(log n) worst case
13:46:18  <indutny>it's not critical for browsers
13:46:46  <indutny>einaros: probably we can implement native module that will provide SecureObject class
13:46:48  <einaros>it will be when peer-to-peer communication passes
13:46:55  <einaros>p2p json dos
13:47:05  <indutny>einaros: seed randomization will work too
13:47:14  <indutny>with same performance as now
13:47:25  <einaros>prone to timing attacks, but yes, it'll at least be better
13:48:05  <bnoordhuis>let's keep it simple for now
13:50:10  <bnoordhuis>piscisaureus_: https://github.com/joyent/node/pull/2433 <- can you check that PR?
13:52:30  <CIA-111>node: Damon Oehlman v0.6 * r744ed46 / lib/repl.js : repl: fix repl.start not passing the `ignoreUndefined` arg to the REPLServer constructor - http://git.io/M8pZ0Q
13:59:36  * mralephjoined
14:00:04  * travis-cijoined
14:00:05  <travis-ci>[travis-ci] joyent/node#161 (v0.6 - 744ed46 : Damon Oehlman): The build passed.
14:00:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/8c3a757...744ed46
14:00:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/458118
14:00:05  * travis-cipart
14:02:07  <mraleph>einaros: my personal opinion is that people who are concerned about hash collisions based DoS should not use Objects (or any hash tables) and put their own data structure in appropriate places to mitigate this kind of attacks.
14:05:27  <mraleph>einaros: that said using per-isolate random seed for hash function is something that can be (easily) done and probably should be done. (again my personal opinion)
14:05:28  <einaros>well there are three solutions, really: (a) avoid hashes, reducing speed for http parsers and so forth, (b) limit amount of accepted properties (e.g. post params), (c) mitigate (effect of) collisions either by randomized seeds or tree'd hash buckets
14:05:36  <einaros>... or a combination of the three
14:12:23  <CIA-111>node: Ben Noordhuis v0.6 * r3f5bb15 / src/udp_wrap.cc : dgram: fix memory leak in error path - http://git.io/kFkBiA
14:19:57  * travis-cijoined
14:19:58  <travis-ci>[travis-ci] joyent/node#162 (v0.6 - 3f5bb15 : Ben Noordhuis): The build passed.
14:19:58  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/744ed46...3f5bb15
14:19:58  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/458167
14:19:58  * travis-cipart
14:28:07  * bradleymeckjoined
14:32:10  * paddybyersquit (Quit: paddybyers)
14:47:36  * mralephquit (Quit: Leaving)
14:50:18  * piscisaureus__joined
14:54:09  * paddybyersjoined
15:05:05  * paddybyersquit (Quit: paddybyers)
15:30:01  * AvianFlujoined
15:47:15  <txdv>increase spead of http parser? like start writing in voodoo machine code for specific arch types?
16:16:14  <bnoordhuis>txdv: sorry?
16:46:00  * paddybyersjoined
17:01:20  * AndreasMadsenjoined
17:04:37  * AndreasMadsen_joined
17:26:13  * isaacsjoined
17:27:50  * ericktjoined
18:08:35  * ljacksonquit (Quit: Leaving)
18:12:05  * dapjoined
18:13:41  <DrPizza>einaros: or (d) use secure hash algorithms in those few situations where it actually matters (e.g. where you're hashing hostile data)
18:22:50  <indutny>einaros: why not just limit incoming data size
18:23:16  <indutny>einaros: you cannot run in collisions if data is too small, accepting mbs of POST data is already a mistake
18:24:18  <indutny>but yeah, randomizing initial seed sounds good too nayway
18:24:23  <indutny>s/nayway/anyway
18:24:32  <indutny>it won't hurt anyone
18:31:26  <CIA-111>node: Ben Noordhuis master * rc24276f / (2 files in 2 dirs): net: defer net.Server 'close' event to next tick - http://git.io/eTHKRA
18:31:31  <bnoordhuis>indutny: https://github.com/joyent/node/issues/2431#issuecomment-3300620
18:34:29  * benviequit
18:37:32  * AndreasMadsen_quit (Remote host closed the connection)
18:37:38  * ericktquit (Quit: erickt)
18:39:12  <indutny>bnoordhuis: hm...
18:39:20  <indutny>bnoordhuis: lets use proplists then :P
18:39:45  <piscisaureus__>adding a random seed to the hashing algorithm is not very difficult and also not extremely inefficient I think
18:39:46  <bnoordhuis>let's stick to linked lists, at least we'll have predictable average and worst case performance
18:40:01  <bnoordhuis>piscisaureus__: yes, but it's not enough
18:40:33  <indutny>bnoordhuis: but that won't save us from JSON.parse :P
18:40:46  <indutny>bnoordhuis: if one will send big object with a lot of collisions
18:40:52  <indutny>it'll still die
18:41:07  <piscisaureus__>bnoordhuis: I doubt that it is not enough
18:41:19  <bnoordhuis>for the record, that quip about linked lists was a nerd joke
18:41:57  <bnoordhuis>piscisaureus__: you can guess the seed by brute force
18:42:10  <bradleymeck>avl tree instead of bucket hash?
18:42:24  <piscisaureus__>bnoordhuis: yeah, by trying out 2M collisions
18:42:32  <piscisaureus__>er, 2 billion
18:42:36  <piscisaureus__>(on average)
18:42:38  <piscisaureus__>sure dude
18:42:42  * travis-cijoined
18:42:42  <travis-ci>[travis-ci] joyent/node#163 (master - c24276f : Ben Noordhuis): The build is still failing.
18:42:42  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/0c3b357...c24276f
18:42:42  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/458856
18:42:42  * travis-cipart
18:42:48  <bnoordhuis>bradleymeck: yes, binary trees don't have that problem but they're a lot slower than hash tables
18:43:25  <piscisaureus__>bnoordhuis: I mean, the best way to blow up node is probably by sending a very big request
18:43:28  <indutny>bnoordhuis: bradleymeck, wasn't talking about replacinh hashmaps
18:43:49  <indutny>bnoordhuis: you can use any balanced tree as a bucket
18:43:52  <indutny>bnoordhuis: that'll help
18:44:04  <bnoordhuis>oh, like that
18:44:16  * paddybyersquit (Quit: paddybyers)
18:44:16  <indutny>bnoordhuis: I think you may even use simple list until bucket will reach some size
18:44:26  <indutny>bnoordhuis: like 1024 items
18:44:35  <indutny>bnoordhuis: and then transform it
18:44:36  <bnoordhuis>piscisaureus__: i'm thinking more of predictable PRNGs
18:44:48  <piscisaureus__>bnoordhuis: we can just get a seed out of openssl
18:45:07  <bnoordhuis>for every object created?
18:45:21  <piscisaureus__>bnoordhuis: I also think v8 has a somewhat high entropy random generator that it uses to set the jit cookie
18:45:21  <bradleymeck>even with avl trees eventually you will hit the collision problem though, just will take a while
18:45:34  <piscisaureus__>bnoordhuis: no you would just do it once, or once per isolate/heap
18:45:50  <mmalecki>hint: please don't be overly paranoid, thank you.
18:46:09  <piscisaureus__>bnoordhuis: the v8 hashing algorithm is incremental, it always starts with 0
18:46:26  <piscisaureus__>if you start it with some other value (that changes every time v8 is started) you should be fine
18:47:00  <bnoordhuis>maybe - at least it'll mitigate the issue
18:47:15  <piscisaureus__>I can have a patch in 30 minues
18:47:32  <piscisaureus__>unless there's some mines under the grass
18:47:43  <bnoordhuis>not to mention vipers
18:48:48  <indutny>piscisaureus__: I think that'll help :)
18:49:05  <indutny>while node.js will remain vulnerable
18:49:15  <indutny>for some ``heavy`` attacks
18:50:58  <piscisaureus__>It's also a trust issue
18:51:02  <piscisaureus__>asp.net has a patch
18:51:04  <piscisaureus__>php has a patch
18:51:18  <piscisaureus__>I mean, we should do something about it *or* have a great story why we won't
18:51:45  <mmalecki>piscisaureus__: it won't scale :D
18:56:03  * mralephjoined
18:57:16  * mikealjoined
19:10:04  * benviejoined
19:12:16  <AndreasMadsen>hi why is node v0.8 "Due in 8 days"
19:12:57  <piscisaureus__>Oh, ignore that
19:14:34  <mraleph>piscisaureus__: yes not starting from zero is the simplest mitigation that should probably be implemented.
19:14:42  <AndreasMadsen>Okay
19:14:49  <piscisaureus__>mraleph: I am doing it now
19:15:25  <mraleph>piscisaureus__: there are inlined hash computations
19:15:48  <mraleph>piscisaureus__: if you are adjusting C++ part you need to adjust them as well
19:15:50  * ericktjoined
19:15:59  <mraleph>piscisaureus__: search for StringHelper::*
19:16:17  <piscisaureus__>Oh, I didn't find those yet
19:16:23  <piscisaureus__>but I assumed there would be
19:16:36  <piscisaureus__>mraleph: where do you want to store the hasher seed?
19:16:47  <piscisaureus__>in Heap or in Isolate?
19:16:52  <AndreasMadsen>ryah: I have fixed all the cluster issues you have reported so far: https://github.com/joyent/node/pull/2388 :)
19:16:55  <mraleph>piscisaureus__: in the isolate I think
19:17:04  <piscisaureus__>kk
19:17:17  <mraleph>piscisaureus__: are you planning to upstream the patch?
19:17:21  <piscisaureus__>mraleph: right now I am using RandomPrivate to bootstrap it btw
19:17:41  <piscisaureus__>mraleph: maybe later we could have another way to do that since RandomPrivate is not super safe
19:17:50  <piscisaureus__>mraleph: I will upstream if I think it's good enough
19:17:53  <mraleph>piscisaureus__: should be fine. I would also use entropy_source instead of RandomPrivate if it is available
19:18:06  <piscisaureus__>mraleph: oh ok
19:18:24  <mraleph>piscisaureus__: V8 allows embedder to pass function that would be used by V8 to seed different things.
19:18:49  <piscisaureus__>mraleph: ah I was just going to propose you add something like that
19:19:07  <piscisaureus__>mraleph: so we can use openssl entropy
19:19:15  <piscisaureus__>mraleph: but it's already there :-)
19:19:46  * AndreasMadsenquit (Remote host closed the connection)
19:20:42  <mraleph>piscisaureus__: http://codesearch.google.com/#OAMlx_jo-ck/src/v8/include/v8.h&exact_package=chromium&q=SetEntropySource&type=cs&l=3076
19:20:58  <piscisaureus__>ah, nice
19:21:04  <piscisaureus__>I think we should do that in node anyway
19:21:20  * AndreasMadsenjoined
19:22:17  <piscisaureus__>ah
19:22:19  <piscisaureus__>StringHelper::GenerateHashInit
19:22:31  <mraleph>yeah I think that's the one
19:22:56  <mraleph>there might be some others, spread around but I don't think so :-)
19:23:15  <piscisaureus__>mraleph: good there are tests :-)
19:25:20  * dapquit (Quit: Leaving.)
19:25:41  * TooTallNatejoined
19:30:21  <piscisaureus__>mraleph: should I make it optional btw?
19:33:01  * bnoordhuisquit (Ping timeout: 240 seconds)
19:33:25  <TooTallNate>piscisaureus__: ping
19:33:34  <piscisaureus__>TooTallNate: yo
19:33:58  <TooTallNate>hey, is { customFds: [0,1,2] } supported on windows?
19:34:02  <TooTallNate>for cp.spawn()?
19:34:37  <piscisaureus__>TooTallNate: I think so
19:34:55  <TooTallNate>ok, just not arbitrary fd's?
19:35:09  <piscisaureus__>TooTallNate: yep
19:35:20  <TooTallNate>ok thanks bud
19:35:52  <mraleph>piscisaureus__: dunno
19:36:17  <mraleph>piscisaureus__: might be a good idea to make it optional
19:36:51  <piscisaureus__>kk
19:38:29  * mikealquit (Quit: Leaving.)
19:39:46  * mikealjoined
19:55:34  <ryah>indutny: sorry i thought you had said yesterday you were working on the DoS problem
19:56:11  <ryah>im merging isolates2
19:57:13  <ryah>i'll land uv_pipe_pair after
19:58:36  * sh1mmerjoined
20:08:35  <CIA-111>node: Ryan Dahl master * r4b3824b / deps/uv/src/win/thread.c : Merge remote branch 'origin/isolates2' - http://git.io/Msj5sA
20:11:46  <pquerna>by the time we are running on 0.6, i guess 0.8 will be out :/
20:12:51  <bradleymeck>pquerna, yea, the version bumps are leading us to just make systems that can live in multiple, and that is taking longer than we hoped
20:15:55  <ryah>the idea it to move faster and faster - because lingering on a single version tends to allow one to make large API changes
20:16:03  <ryah>s/one/us/
20:16:27  <pquerna>yes, i think its fine moving forward, its motivating us to kill C++ extensions too :)
20:16:44  <ryah>:)
20:16:48  <pquerna>have a v0.6 branch in a pull request, just takes awhile to validate everything
20:17:08  <ryah>we need to fix that ABI warning thing that you were doing last year
20:17:18  <ryah>so that we can have a sane error at least
20:17:23  <pquerna>+1
20:17:27  <mjr_>ryah: any new insights into the http parser crash?
20:17:49  <ryah>mjr_: my theory is the same - and if that's the case i should be able to demo it - which im trying to
20:18:18  <ryah>https://gist.github.com/1536013
20:18:28  <ryah>but it doesn't seem to be crashing
20:18:33  <AndreasMadsen>ryah: could you review the new cluster patch?
20:18:39  <ryah>AndreasMadsen: yes, later today
20:19:08  <ryah>mjr_: i'm rather sure we're keeping a dead pointer in a StringRef
20:19:18  <ryah>mjr_: and that it should be flushed out to JS before continuing
20:19:23  <AndreasMadsen>Sure just make a comment on github :)
20:19:45  <ryah>and by "rather sure" i mean "have a hunch"
20:20:01  * travis-cijoined
20:20:01  <travis-ci>[travis-ci] joyent/node#164 (master - 4b3824b : Ryan Dahl): The build is still failing.
20:20:01  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/c24276f...4b3824b
20:20:01  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/459042
20:20:01  * travis-cipart
20:21:04  <mjr_>ryah: oh, this test is interesting with the gc() loop. Does that work?
20:21:32  <ryah>not sure. going to step through the c++ stuff now and see what's happening
20:21:38  <ryah>it should!
20:22:46  <ryah>im creating these 10MB buffers in between in order to flush the pool
20:23:20  <mjr_>Are you sure that moves them forward, since you don't keep any reference to them?
20:23:48  <mjr_>If you do: Buffer(10 * 1024 * 1024); gc(); Won't that GC the new buffer immediately?
20:24:32  <mjr_>I guess who knows, but it certainly COULD reclaim that buffer immediately, or it could not.
20:24:57  <ryah>actually this isn't flushing the pool...
20:25:25  * bradleymeckquit (Ping timeout: 240 seconds)
20:25:54  * paddybyersjoined
20:27:28  <mjr_>Is there a performance impact on the one-liner flush() change?
20:27:56  <mjr_>If it's minor, I'd be willing to roll that out and see if it fixes anything.
20:29:26  <ryah>it's not working - flushing mid-header needs be pushed into JS differently
20:29:35  <ryah>Flush supposes it's at the end of a header/value pair
20:29:46  <ryah>(at the end of the 32nd header/value pair)
20:30:13  <ryah>so before i change the code to handle that - i want to prove that that is what's really happening...
20:30:19  * AndreasMadsenquit (Remote host closed the connection)
20:30:19  <mjr_>ahh, right. This seems to happen while in the middle of parsing the User-Agent header.
20:30:25  <ryah>yeah
20:30:59  <mjr_>Sure, OK. Let me know if you need anything from me.
20:31:01  <ryah>mjr_: what we can do for you, if you're desperate, is revert the optimization
20:31:19  <mjr_>I'd rather just hang in there for a fix.
20:31:28  <mjr_>A real fix so we can all live better lives.
20:31:44  <ryah>ok - that would be interesting too just to prove that the problem is indeed somewhere in the optimization
20:31:51  <ryah>yep
20:31:59  <ryah>agreed
20:32:06  <mjr_>If you think reverting the fix is a path toward better understanding and fixing the problem, I'm open to that as well.
20:32:12  <mjr_>Er, reverting the optimization.
20:32:19  <ryah>that's an easy option if you ever want to take it
20:32:50  <mjr_>I don't need to do that right now unless it'll give you useful learnings.
20:35:38  * nathanpalmerquit (Quit: nathanpalmer)
20:39:30  <ryah>i want to have a subset of V8's API that we wrap in aheader
20:39:37  <ryah>so that we can control what changes
20:39:53  * AndreasMadsenjoined
20:39:59  <ryah>i think for the purposes of addons, it can be limited very much
20:41:54  * paddybyersquit (Quit: paddybyers)
20:52:11  * mikealquit (Quit: Leaving.)
20:58:04  * AndreasMadsenquit (Ping timeout: 240 seconds)
20:58:19  * AndreasMadsenjoined
20:58:58  <ryah>got it :)
20:59:24  <ryah>bad mem access only detectable with valgrind - but got it :)
21:06:50  <txdv>i can't believe it: a basic naked tcp server connect accept and immediate close is faster on node.js compared to my c++ wrapper
21:06:59  <txdv>using std::function
21:07:18  <txdv>what is this sorcery?
21:07:28  * isaacsquit (Read error: Connection reset by peer)
21:07:59  * isaacsjoined
21:08:47  <ryah>txdv: how are you measure it ?
21:09:10  <txdv>ab -c1000 -n10000
21:10:12  <txdv>and I used http.createServer while the C++ variant used just a tcpserver/tcpsockets
21:10:29  <ryah>our http server is highly optimized
21:10:40  <ryah>strace it - you're probably doing extra syscalls
21:11:52  <mmalecki>txdv: please blog about it, it's always fun to see nerdfights :)
21:12:19  <txdv>there is a big possibility that my compilation flags sucks, etc
21:12:30  <txdv>because i am fairly new to c++
21:12:53  <ryah>mjr_: https://gist.github.com/1536224
21:13:01  <txdv>knew the basics all the time, but c++11 c++ is usable again
21:13:15  <txdv>but mmalecki ok, I will, I will create a blog in c++ and blog about it xD
21:13:49  <mjr_>ryah: awesome, vallgrind to the rescue.
21:13:56  <mmalecki>txdv: yes, please :)
21:18:10  * AndreasMadsenquit (Ping timeout: 252 seconds)
21:20:56  <txdv>ryah: http://pastebin.com/a9mK17Wy this is what one request returned
21:20:59  <txdv>-c1 -n1
21:21:54  <txdv>ryah: I heared a radio cast with you, the one where you were bashing the germans for being racist - you wrote a c++ web framework?
21:23:30  * AndreasMadsenjoined
21:26:37  <ryah>nope
21:31:25  <ryah>it's a little annoying that this bug doesn't cause a segfaul
21:31:40  <ryah>s/bug/test
21:31:52  <mjr_>What does it do?
21:32:03  <ryah>nothing
21:32:04  <mjr_>Just print a valgrind warning?
21:32:06  <ryah>yeah
21:32:39  <ryah>im going to create a ticket for this issue - we don't have one yet, do we?
21:33:12  * AndreasMadsenquit (Remote host closed the connection)
21:33:14  <piscisaureus__>mraleph: hey, yt
21:33:37  <piscisaureus__>mraleph: everything seems to work but the serialization/deserialization tests crash now
21:34:06  <piscisaureus__>mraleph: could there be a third hash path?
21:36:02  <ryah>mjr_: https://github.com/joyent/node/issues/2438
21:36:51  <mraleph>piscisaureus__: what's the stack trace for those tests?
21:37:05  <mraleph>piscisaureus__: are you running debug tests?
21:37:15  <mjr_>ryah: are all of the crashes in StringPtr::Update?
21:37:21  <mraleph>piscisaureus__: more information :-)
21:37:40  <ryah>mjr_: no but memory is getting corrupted
21:37:40  <CIA-111>node: Ryan Dahl v0.6 * r432a2e4 / test/simple/test-http-parser-bad-ref.js :
21:37:41  <CIA-111>node: Add test for #2438
21:37:41  <CIA-111>node: Unfortunately valgrind must be used to see the bad read. It would be nice if
21:37:41  <CIA-111>node: we could improve this test to cause a segfault. - http://git.io/B-xJfQ
21:37:42  <piscisaureus__>mraleph: https://gist.github.com/1536325
21:38:01  <ryah>mjr_: i've only been able to demo a bad read in StringPtr::Update
21:38:05  <ryah>there may be other problems
21:38:15  <mraleph>piscisaureus__: zomg
21:38:26  <mraleph>piscisaureus__: ah oh
21:38:34  <mraleph>piscisaureus__: I just realized
21:38:43  <mraleph>piscisaureus__: the life is not simple
21:39:03  <piscisaureus__>pour your heart out, mralpeh
21:39:14  <mraleph>piscisaureus__: you can't have random seed for the hash, because then you need to reconfigure your snapshot to use the same seed.
21:39:39  <mraleph>otherwise string objects that are in snapshot will have hashes incompatible with the whole system.
21:39:46  <piscisaureus__>heh, fun
21:39:48  <ryah>mjr_: okay - well let's fix this bug and see what happens
21:39:49  <mjr_>ryah: any different results with efence / guard malloc?
21:40:00  <piscisaureus__>mraleph: can we levarage the relocation mechanism to do it?
21:40:01  <ryah>mjr_: let me try...
21:40:39  <piscisaureus__>I mean it'll mostly be a dword that needs to be patched
21:40:56  <mraleph>nope
21:41:07  <mraleph>imaging those strings participate in hash table
21:41:17  <ryah>% LD_PRELOAD=libefence.so.0.0 ./node --expose_gc test/simple/test-http-parser-bad-ref.js
21:41:20  <ryah>ElectricFence: Registering with atexit().
21:41:21  <mraleph>changing hash implies rehashing.
21:41:23  <ryah>ElectricFence: If this hangs, change the library load order with LD_PRELOAD.
21:41:25  <ryah>ElectricFence: Registration was successful.
21:41:28  <ryah>parse the first part of the message
21:41:30  <ryah>parse the second part of the message
21:41:33  <ryah>zsh: segmentation fault LD_PRELOAD=libefence.so.0.0 ./node --expose_gc
21:41:35  <ryah>-139-
21:43:21  <mraleph>piscisaureus__: so I guess we are out of luck here.
21:45:41  * travis-cijoined
21:45:41  <travis-ci>[travis-ci] joyent/node#165 (v0.6 - 432a2e4 : Ryan Dahl): The build was broken.
21:45:41  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/3f5bb15...432a2e4
21:45:41  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/459236
21:45:41  * travis-cipart
21:47:47  <piscisaureus__>hmm
21:56:19  * mikealjoined
21:56:22  <indutny>mraleph: piscisaureus__ cryptoobjects ftw!
21:57:52  * bradleymeckjoined
21:58:29  * mikeal1joined
21:58:59  * sh1mmer_joined
21:59:42  * mikealquit (Read error: Connection reset by peer)
21:59:46  * sh1mmerquit (Read error: Connection reset by peer)
21:59:47  * sh1mmer_changed nick to sh1mmer
22:04:02  * paddybyersjoined
22:11:24  * paddybyersquit (Quit: paddybyers)
22:25:30  <piscisaureus__>meh
22:25:36  * piscisaureus__goes home
22:28:32  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
22:43:14  * bnoordhuisjoined
23:34:17  * bradleymeckquit (Ping timeout: 240 seconds)
23:37:14  * mikealjoined
23:39:25  * mikeal1quit (Ping timeout: 240 seconds)
23:47:48  * mikealquit (Quit: Leaving.)