00:01:49  * isaacsquit (Remote host closed the connection)
00:14:49  * toothrjoined
00:20:58  <bnoordhuis>ircretary: tell igorzi https://github.com/joyent/node/pull/2861 <- does msft still want pkcs12 support?
00:20:58  <ircretary>bnoordhuis: I'll be sure to tell igorzi
00:25:54  <CIA-155>node: Kyle Robinson Young master * rc9e6d36 / (4 files): doc: typo fixes - http://git.io/frpLQg
00:25:54  <CIA-155>node: Kyle Robinson Young master * re02d5c9 / doc/api/stdio.markdown : doc: add args to console methods - http://git.io/TTeQtw
00:25:55  <CIA-155>node: Garen Torikian master * r6cacb9a / doc/community/index.html : doc: add Cloud9 links to docs - http://git.io/cRHR6g
00:27:39  * loladirojoined
00:40:43  * mikealjoined
00:54:13  * Ariajoined
00:54:22  * ericktquit (Ping timeout: 246 seconds)
01:02:47  * toothrquit (Quit: here we are)
01:04:35  * orlandovftwquit (Ping timeout: 250 seconds)
01:15:40  <dap>mjr_, bnoordhuis, and anyone else with the opportunity to use MDB for debugging node on illumos: you may find http://dtrace.org/blogs/eschrock/2005/05/10/gdb-to-mdb-migration-part-one/ and http://dtrace.org/blogs/eschrock/2005/06/17/gdb-to-mdb-migration-part-two/ useful.
01:17:30  * pieternquit (Ping timeout: 265 seconds)
01:19:07  * dapquit (Quit: Leaving.)
01:23:03  * ljacksonjoined
01:25:30  * piscisaureus_joined
01:25:59  <piscisaureus_>indutny: hey
01:26:02  <piscisaureus_>hello everyone
01:26:57  * loladiroquit (Remote host closed the connection)
01:27:39  * loladirojoined
01:27:42  <piscisaureus_>ircretary: tell indutny Hey. What's up?
01:27:42  <ircretary>piscisaureus_: I'll be sure to tell indutny
01:29:23  * bnoordhuisquit (Ping timeout: 245 seconds)
01:29:44  <loladiro>piscisaureus_: BTW, libuv is now build by default with Julia, though since it's part of a greater build system rewrite, we didn't introduce the features that are based on it yet until we are sure that we didn't break anything else
01:30:06  <piscisaureus_>loladiro: cool
01:30:44  <piscisaureus_>loladiro: will be more cool when you guys actually use it :-)
01:31:49  <loladiro>piscisaureus_: Yeah, as I said there's a few issues to figure out, but we'll probably start using it in the Web REPL soon as that's a pure C app and doesn't have any memory management issues we need to worry about
01:33:15  * felixgejoined
01:34:53  <piscisaureus_>cool
01:35:26  <piscisaureus_>creationix: congrats with Charlotte Mae :-)
01:36:09  * abraxasjoined
01:36:18  * brsonquit (Quit: leaving)
01:39:35  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:41:12  * isaacsjoined
01:43:25  * bulatshakirzyanojoined
01:49:01  * mikealquit (Quit: Leaving.)
01:49:40  <TooTallNate>isaacs: i'm fixing
01:50:40  <isaacs>TooTallNate: oh, i didn't realize that'd been merged inalready :)
01:50:51  <isaacs>it was in my "to be reviewed" stack of tabs in chrome :0
01:50:53  <isaacs>:)
01:51:01  <isaacs>big backlog
01:51:04  <TooTallNate>ben ok'd it earlier
01:52:56  * TheJHquit (Ping timeout: 248 seconds)
01:53:33  <TooTallNate>isaacs: https://github.com/TooTallNate/node/commit/getWindowSize-emit
01:53:47  <isaacs>perfecto
01:53:54  <isaacs>yeah, ben tries to slip throws past me
01:53:57  <isaacs>but i always catch them!!
01:54:10  * isaacsrimshot
01:54:13  <TooTallNate>you triple-check every 'throw' keyword, eh?
01:54:20  <TooTallNate>proabably a good idea
01:54:22  <isaacs>it was just a joke
01:54:40  <TooTallNate>:p
01:54:53  <isaacs>get it... ben TRIES to slip throws past me but I always CATCH them
01:55:03  * isaacsomg it's getting EVEN LESS funny
01:55:04  * felixgequit (Quit: felixge)
01:55:22  <TooTallNate>isaacs: well you're at like a triple-double at this point
01:56:39  * Arialaughs
01:56:52  <CIA-155>node: Nathan Rajlich master * rf4403f9 / lib/tty.js : tty: emit "error" instead of throwing when getWindowSize() fails - http://git.io/zkQesA
01:57:36  <isaacs>TooTallNate: so, just to reiterate: the principle should be that we only throw if it's the immediate result of programmer error.
01:57:45  <isaacs>the console.timeEnd thing is a good example of that.
01:58:08  <TooTallNate>ya for sure
01:58:08  <isaacs>though, domains make this less of an issue, of course
01:58:12  <TooTallNate>it's kinda a weird one
01:58:15  <isaacs>yeah
01:58:19  <isaacs>it *should* never happen
01:58:20  <TooTallNate>because ideally that one would throw on getWindowSize()
01:58:33  <TooTallNate>ya, and it should never happen :D
01:58:41  <isaacs>right, but getWindowSize only gets called from SIGWINCH, which you don't control
01:58:44  <TooTallNate>i only encountered it because of a rouge tty implementation
01:58:48  <TooTallNate>which is not fixed :D
01:58:52  <TooTallNate>*now
01:58:54  <isaacs>rouge? like... a red one?
01:59:17  <Aria>Rouge in your TTY will definitely cause problems.
01:59:23  <TooTallNate>https://github.com/chjj/pty.js/commit/579b91f5fd2536478038c81c41457f8473723ee8
01:59:24  <Aria>The stuff is just conductive enough to be a real pain.
01:59:32  <TooTallNate>hahaha rouge
01:59:33  <Aria>And if it gets into your memory controller...
01:59:38  <isaacs>oh, rogue
01:59:45  <TooTallNate>ya
01:59:49  <TooTallNate>:p
02:00:08  <isaacs>we are just a bucket of puns tonight
02:00:25  <TooTallNate>and that was my 100th commit :D
02:00:30  <TooTallNate>now i can stop counting
02:02:03  * ericktjoined
02:02:38  * orlandovftwjoined
02:09:31  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:12:50  * mikealjoined
02:15:01  * mikealquit (Client Quit)
02:28:10  * orlandovftwquit (Ping timeout: 246 seconds)
02:44:44  * pieternjoined
02:45:01  * pieternquit (Remote host closed the connection)
03:27:44  * mikealjoined
03:29:04  * loladiroquit (Ping timeout: 246 seconds)
03:31:38  * loladirojoined
03:33:54  * c4miloquit (Ping timeout: 272 seconds)
03:47:19  * Ariaquit (Remote host closed the connection)
03:48:47  * AlbireoXquit (Ping timeout: 265 seconds)
03:53:39  * AlbireoXjoined
03:54:22  * isaacsquit (Remote host closed the connection)
04:05:40  * Marakjoined
04:05:49  * Marakpart
04:09:28  * mikealquit (Quit: Leaving.)
04:16:54  * igorzijoined
04:25:45  * loladiroquit (Ping timeout: 276 seconds)
04:30:44  * mikealjoined
04:35:23  * ericktquit (Quit: erickt)
05:06:16  * dshaw_quit (Quit: Leaving.)
05:35:32  * c4milojoined
05:41:50  * paddybyersjoined
05:43:46  * dshaw_joined
05:58:02  * dshaw_quit (Quit: Leaving.)
06:39:19  * stephankquit (Quit: *Poof!*)
06:41:27  * TheJHjoined
06:46:10  * TheJHquit (Ping timeout: 265 seconds)
06:47:48  * TheJHjoined
07:55:14  * rendarjoined
08:06:28  * c4milo_joined
08:09:48  * c4miloquit (Ping timeout: 256 seconds)
08:13:21  <mjr_>I have seen the future of node memory leak detection.
08:13:29  <mjr_>It exists. All hope is not lost.
08:18:10  * c4milo_quit (Ping timeout: 246 seconds)
08:18:22  * mralephjoined
08:24:21  <DrPizza>step 1: rewrite node in javascript
08:24:33  <DrPizza>step 2: there is no step 2, it's garbage collection, no more leaks!
09:04:59  * mralephquit (Quit: Leaving.)
09:06:07  * AvianFluquit (Quit: Leaving)
09:06:22  * txdvjoined
09:17:44  * mralephjoined
09:20:13  * mmalecki[zzz]changed nick to mmalecki
09:21:24  <mmalecki>mjr_: please do tell :)
09:53:31  * pquernaquit (Read error: Operation timed out)
09:53:36  * avsejquit (Read error: Operation timed out)
09:53:42  * pquernajoined
09:53:45  * avsejjoined
09:54:49  * rendarquit
09:56:49  * rendarjoined
09:56:50  * rendarquit (Excess Flood)
09:57:08  * rendarjoined
09:57:08  * rendarquit (Excess Flood)
09:57:23  * rendarjoined
09:57:23  * rendarquit (Excess Flood)
09:57:40  * rendarjoined
10:15:04  * abraxasquit (Remote host closed the connection)
11:41:17  * theColejoined
12:00:05  * bnoordhuisjoined
12:19:45  * theColequit (Quit: theCole)
12:21:12  * theColejoined
12:31:06  * loladirojoined
12:43:13  * piscisaureus_joined
12:43:16  * theCole_joined
12:43:37  <saghul>hi, anyone else getting "connection_fail" test failing on Windows? The connection callback is never called apparently
12:44:09  <piscisaureus_>saghul: master?
12:44:14  <saghul>piscisaureus_ yep
12:45:00  <saghul>FWIW connection_fail_doesnt_auto_close also fails
12:45:03  <piscisaureus_>saghul: maybe it's just timing out. Can you run "test/run-tests connection_fail connection_fail" ?
12:45:38  <piscisaureus_>saghul: it works for me
12:46:15  * theColequit (Ping timeout: 276 seconds)
12:46:36  <saghul>piscisaureus_ hum, I just did a fresh checkout, if I run the test individually it never returns
12:47:11  <saghul>i'll restart the VM just in case
12:47:31  <piscisaureus_>saghul: what windows version are you using?
12:47:43  <piscisaureus_>saghul: also, in case of vista or later, are you running as admin?
12:47:44  <saghul>7, 32bits, with MinGW32
12:48:13  <saghul>nope, IIRC i'm an advanced user or something like that, i'll check
12:48:44  <saghul>ok, I am admin
12:48:58  <piscisaureus_>saghul: type cmd in the start menu search box. It will find "cmd.exe". Right click that and select "run as administrator"
12:50:26  <saghul>piscisaureus_ ok, I'm recompiling, lets see
12:50:47  <piscisaureus_>saghul: there should be no need to recompile... but it doesn't hurt :-)
12:53:35  <saghul>piscisaureus_ hum, apparently it was a false alarm :-S test is passing now, sorry for the noise!
12:53:55  <saghul>though I didn't really change anything, other than a restart o_O
12:54:14  <piscisaureus_>saghul: np
12:55:52  <saghul>piscisaureus_ btw, on unices when a tcp handle is just initialized uv_is_readable returns true, but on Windows doesn't, is this expected?
12:56:19  <piscisaureus_>saghul: no, that's not expected.
12:56:24  <saghul>sorry, just the opposite
12:56:32  <saghul>on windows i returns true
12:56:39  <saghul>*it
12:56:50  <piscisaureus_>saghul: it should be readable only when you can actually read from it :-)
12:57:46  <saghul>piscisaureus_ yep. I spotted it on my test suite for pyuv, I'll write a test for libuv and submit it
12:57:51  <piscisaureus_>saghul: so this is probably a bug.
12:57:57  <piscisaureus_>saghul: nice.
12:58:09  <piscisaureus_>tests for this would be very helpful
12:58:37  <saghul>i'll write one for sure :-)
12:58:42  <piscisaureus_>saghul: if you can manage, also write a test for other stream types (like pipe)
12:58:58  <saghul>ok, will do!
13:02:10  * theCole_quit (Quit: theCole_)
13:03:24  * theColejoined
13:14:06  * loladiro_joined
13:16:48  * loladiroquit (Ping timeout: 276 seconds)
13:21:04  <CIA-155>node: Shigeki Ohtsu master * r94f1fee / (3 files in 3 dirs): udp: make getsockname() return address family name - http://git.io/mRuh4g
13:21:04  <CIA-155>node: Ben Noordhuis master * re747daf / src/udp_wrap.cc : udp: make variable names consistent - http://git.io/oN0Kfg
13:21:04  <CIA-155>node: Ben Noordhuis master * rb45a108 / src/udp_wrap.cc : udp: slightly optimize address family property - http://git.io/SUuALg
13:21:05  <CIA-155>node: Kyle Robinson Young master * r6ba3e68 / doc/api/fs.markdown :
13:21:05  <CIA-155>node: doc: correct return value of string-based fs.readSync
13:21:05  <CIA-155>node: Closes #2330 - http://git.io/tYc4lw
13:21:05  <CIA-155>node: Yi, EungJun master * r4bd54da / (doc/api/path.markdown lib/path.js test/simple/test-path.js): path: add path.sep to get the path separator. - http://git.io/lV20iw
13:22:17  * bnoordhuisis afk
13:39:13  * c4milojoined
13:48:57  * mmaleckichanged nick to mmalecki[away]
13:55:27  <piscisaureus_>we need a mapping for exdev
13:55:30  <piscisaureus_>on windows
14:03:01  <indutny>bnoordhuis: hey
14:03:07  <indutny>bnoordhuis: about that EIO issue
14:04:20  <indutny>bnoordhuis: as far as I can see - it's already in libuv, right? XX(55, EIO, "i/o error")
14:04:35  <indutny>uv.h:128
14:12:37  <indutny>piscisaureus_: yt?
14:14:26  <piscisaureus_>indutny: sup?
14:14:54  <indutny>piscisaureus_: can we use cygwin's list of errors that can be used as analog of EIO
14:15:01  <piscisaureus_>indutny: yeah
14:15:07  <piscisaureus_>indutny: go ahead
14:15:21  <indutny>piscisaureus_: ok
14:15:30  <piscisaureus_>indutny: but do not replace any mappings that are already there
14:15:38  <indutny>ah, ok
14:15:40  <indutny>will check
14:15:41  <piscisaureus_>indutny: cygwin's mappings are kinda questionable sometimes :-
14:15:52  <indutny>:)
14:15:54  <indutny>indeed
14:16:06  <piscisaureus_>indutny: well your compiler will just shoot at you if you have 2 mappings for something
14:16:27  <indutny>yes, but I'll need to install windows vm first
14:16:35  <indutny>piscisaureus_: can I ask you test it?
14:16:38  <piscisaureus_>indutny: sure
14:16:57  <indutny>DEVICE_DOOR_OPEN
14:17:06  <indutny>ERR_POWER_PLUG_NOT_PULLED
14:17:08  <indutny>hahaha
14:17:11  <piscisaureus_>ERROR_DEVICE_DOOR_OPEN that would be
14:17:23  <indutny>you think so?
14:17:33  <indutny>ah, indeed
14:17:43  <piscisaureus_>indutny: yeah all win32 errors start with ERROR_
14:20:02  <indutny>kk
14:20:05  <indutny>I see
14:22:17  <CIA-155>libuv: Bert Belder master * r32f6f6e / src/win/error.c : Windows: map ERROR_NOT_SAME_DEVICE to UV_EXDEV - http://git.io/nu5GCw
14:22:18  <CIA-155>libuv: Bert Belder master * rc7edea9 / src/win/error.c : Merge branch 'v0.6' - http://git.io/x1rLQQ
14:22:18  <CIA-155>libuv: Bert Belder v0.6 * r32f6f6e / src/win/error.c : Windows: map ERROR_NOT_SAME_DEVICE to UV_EXDEV - http://git.io/nu5GCw
14:22:36  <indutny>haha
14:22:55  <piscisaureus_>indutny: wut?
14:23:05  <piscisaureus_>indutny: just noticed this, let's get it fixed right
14:23:18  <indutny>UV_EIO is so generic
14:24:19  * travis-cijoined
14:24:20  <travis-ci>[travis-ci] joyent/libuv#243 (master - c7edea9 : Bert Belder): The build is still failing.
14:24:20  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/d13b1e0...c7edea9
14:24:20  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1219227
14:24:20  * travis-cipart
14:24:34  * travis-cijoined
14:24:35  <travis-ci>[travis-ci] joyent/libuv#244 (v0.6 - 32f6f6e : Bert Belder): The build is still failing.
14:24:35  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/e2b6f42...32f6f6e
14:24:35  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1219229
14:24:35  * travis-cipart
14:25:07  <piscisaureus_>yeah UV_EIO just means "shit hit the fan, git up buddy":
14:25:51  <indutny>yeah, it's -1 in unix AFAIK
14:25:59  <indutny>that means I just do not want any special case for that crap
14:26:37  <indutny>piscisaureus_: https://github.com/joyent/libuv/pull/398
14:26:52  <indutny>ooops
14:26:56  <indutny>wrong issue number
14:26:58  <indutny>#3180
14:27:15  <indutny>fixed
14:27:29  * indutnythis is a real one https://github.com/joyent/libuv/issues/356
14:27:32  <piscisaureus_>ok, trying
14:27:57  <indutny>oops
14:28:02  <indutny>DEVICE_IN_USE is wrong
14:28:23  <piscisaureus_>indutny: UV_EIO is not defined...
14:28:29  <indutny>huh
14:28:40  <indutny>ok, one minute
14:28:42  <piscisaureus_>indutny: oh that may be because I am trying to land it on 0.6
14:28:46  <piscisaureus_>indutny: can you target that?
14:28:59  <indutny>probably
14:29:02  <indutny>let me see
14:29:10  <piscisaureus_>indutny: it's nice if these mappings also make it into node 0.6.next
14:32:12  <indutny>piscisaureus_: https://github.com/joyent/libuv/pull/399
14:32:57  <indutny>oops
14:32:59  <indutny>but not in master
14:33:09  <indutny>that was done by occasion
14:33:26  <piscisaureus_>indutny: you seem to have an oops day today
14:33:26  * loladirojoined
14:33:36  <indutny>piscisaureus_: I always have oops day :P
14:33:45  <indutny>that's my bad side, definitely
14:33:49  * indutnychanged nick to oops-man
14:33:53  <oops-man>you see
14:34:10  * oops-manchanged nick to indutny
14:34:31  <piscisaureus_>indutny: 399 works for me
14:34:36  <indutny>cool
14:34:43  <piscisaureus_>indutny: I applied it to 0.6 and it looks fine.
14:34:43  <indutny>it's introducing new EAGAIN mapping
14:34:49  <piscisaureus_>indutny: shall I land it
14:34:52  <piscisaureus_>huh rly?
14:35:06  <indutny>yeah, but only one
14:35:12  <indutny>I may port more from cygwin if need it
14:35:24  <indutny>I just added that mapping for EIO by occasion
14:35:34  <indutny>then I realized that it's EAGAIN
14:35:48  * loladiro_quit (Remote host closed the connection)
14:35:59  <piscisaureus_>indutny: I don't understand.
14:36:04  <piscisaureus_>indutny: https://github.com/indutny/libuv/commit/a5c4dddaffde397b4e93df2f26dd5fe2689c0e27
14:36:06  <indutny>piscisaureus_: ok, better remove it
14:36:12  <piscisaureus_>indutny: no explain
14:36:15  <indutny>that's wrong commit
14:36:27  <indutny>https://github.com/indutny/libuv/commit/5daa50182f153bf60f33f299c540796e94c84472
14:36:59  <piscisaureus_>indutny: maybe it's alright... but ehm
14:37:06  <indutny>lets remove it for now, but we may consider adding it in another commit
14:37:12  <indutny>probably with other mappings from cygwin
14:37:12  <piscisaureus_>indutny: when would you get ERROR_DEVICE_IN_USE ?
14:37:25  <indutny>piscisaureus_: I seen it here http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/errno.cc?rev=1.87&content-type=text/x-cvsweb-markup&cvsroot=src
14:37:58  <piscisaureus_>indutny: hmm.
14:38:06  <piscisaureus_>indutny: yeah, let's not.
14:38:16  <indutny>ok, force pushed my branch
14:38:21  <indutny>refresh PR page
14:38:22  <piscisaureus_>indutny: seems that EBUSY would me more appropriate. I will dig up the commit log
14:38:41  <indutny>piscisaureus_: that error happens only on system malfunction
14:38:45  <indutny>according to that http://www.votedemos.com/error_device_in_use.php
14:39:19  <piscisaureus_>indutny: hahahahaha
14:39:22  <piscisaureus_>indutny: don't trust that
14:39:36  <piscisaureus_>indutny: that's one of these spam sites that try to sell you crap ware
14:39:45  <piscisaureus_>indutny: they just say that for any windows error code
14:40:25  <indutny>piscisaureus_: oh, windows errors are so vague
14:40:29  <indutny>piscisaureus_: :P
14:41:02  <indutny>piscisaureus_: http://msdn.microsoft.com/en-us/library/windows/desktop/aa385427(v=vs.85).aspx
14:41:10  <indutny>piscisaureus_: ERROR_DEVICE_IN_USE
14:41:11  <indutny>The device is in use by an active process and cannot be disconnected.
14:41:19  <indutny>piscisaureus_: looks like some sort of USB disconnection error
14:41:49  <piscisaureus_>indutny: can you squash your PR ?
14:41:56  <indutny>piscisaureus_: yep
14:42:52  <piscisaureus_>indutny: ah ok that happens when you try to safely disconnect an usb device
14:43:00  <indutny>piscisaureus_: yeah
14:43:10  <indutny>piscisaureus_: squashed
14:43:16  <piscisaureus_>indutny: so EAGAIN is definitely not appropriate... EBUSY would be
14:43:18  <indutny>piscisaureus_: not used in libuv
14:43:24  <indutny>piscisaureus_: so it doesn't matter so far
14:44:11  <indutny>though some new EIO mapping ain't used anywhere too
14:44:12  <txdv>what coud EADDRNOTAVAIL while connecting mean?
14:44:33  <indutny>txdv: ip address doesn't exists?
14:44:38  <indutny>no ACK was received
14:45:01  <indutny>ah, no
14:45:20  <indutny>txdv: it's raised when you've exhausted number of allowed connections
14:45:57  <piscisaureus_>txdv: also, it can be that you tried to bind() to a specific port/interface that is not available
14:46:18  * pfox___joined
14:46:21  <piscisaureus_>txdv: some OSes don't report this error from bind(), but they make a subsequence connect() or listen() fail
14:46:31  <piscisaureus_>txdv: so libuv always does that
14:47:17  <indutny>yeah, that too
14:47:20  <CIA-155>libuv: Fedor Indutny v0.6 * r0efa3cf / (include/uv.h src/unix/error.c src/win/error.c): err: handle EIO errors on win/unix - http://git.io/hIisqw
14:47:27  <indutny>piscisaureus_: what about master?
14:47:33  <piscisaureus_>indutny: a sec
14:47:38  <indutny>piscisaureus_: lets wait for travis, btw
14:47:50  <indutny>piscisaureus_: but it builds fine on linux
14:47:52  <indutny>err, osx
14:48:00  <indutny>so you decide
14:49:05  * travis-cijoined
14:49:05  <travis-ci>[travis-ci] joyent/libuv#245 (v0.6 - 0efa3cf : Fedor Indutny): The build is still failing.
14:49:05  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/32f6f6e...0efa3cf
14:49:05  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1219402
14:49:05  * travis-cipart
14:49:48  <txdv>ok thanks
14:51:27  <indutny>piscisaureus_: looks like it isn't introducing any new errors, right?
14:51:40  <piscisaureus_>indutny: yeah, will merge
14:51:43  <piscisaureus_>indutny: a sec
14:52:59  * isaacsjoined
14:55:28  <CIA-155>libuv: Fedor Indutny master * r0efa3cf / (include/uv.h src/unix/error.c src/win/error.c): err: handle EIO errors on win/unix - http://git.io/hIisqw
14:55:28  <CIA-155>libuv: Maciej Małecki master * redb40b1 / (include/uv.h src/unix/error.c):
14:55:28  <CIA-155>libuv: unix: map `EROFS` to `UV_EROFS`
14:55:28  <CIA-155>libuv: Conflicts:
14:55:28  <CIA-155>libuv: src/unix/error.c - http://git.io/HOSL-Q
14:55:28  <CIA-155>libuv: Ben Noordhuis master * r936795a / src/win/error.c : windows: map ERROR_WRITE_PROTECT to UV_EROFS - http://git.io/bB_hGA
14:55:29  <CIA-155>libuv: Bert Belder master * r6367da2 / (src/unix/error.c src/win/error.c): Merge branch 'v0.6' - http://git.io/AO8BMw
14:55:30  <CIA-155>libuv: Maciej Małecki v0.6 * redb40b1 / (include/uv.h src/unix/error.c):
14:55:31  <CIA-155>libuv: unix: map `EROFS` to `UV_EROFS`
14:55:31  <CIA-155>libuv: Conflicts:
14:55:32  <CIA-155>libuv: src/unix/error.c - http://git.io/HOSL-Q
14:55:32  <CIA-155>libuv: Ben Noordhuis v0.6 * r936795a / src/win/error.c : windows: map ERROR_WRITE_PROTECT to UV_EROFS - http://git.io/bB_hGA
14:55:40  <indutny>great
14:56:31  * TheJHquit (Read error: Connection timed out)
14:56:57  * TheJHjoined
14:57:36  <indutny>hey people
14:57:43  <indutny>where is AndreasMadsen?
14:58:31  * travis-cijoined
14:58:32  <travis-ci>[travis-ci] joyent/libuv#247 (v0.6 - 936795a : Ben Noordhuis): The build is still failing.
14:58:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/0efa3cf...936795a
14:58:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1219451
14:58:32  * travis-cipart
14:58:41  * travis-cijoined
14:58:42  <travis-ci>[travis-ci] joyent/libuv#246 (master - 6367da2 : Bert Belder): The build is still failing.
14:58:42  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/c7edea9...6367da2
14:58:42  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1219448
14:58:42  * travis-cipart
14:59:02  <indutny>isaacs: what do you think about killing cluster's workers if master has died
14:59:13  <isaacs>indutny: i think that's probably a great idea
14:59:14  <indutny>i.e. if worker has received SIGHUP signal
14:59:21  <isaacs>oh, no, not sighup
14:59:33  <isaacs>on sighup i'm gracefully restarting them one by one
14:59:39  <isaacs>sigint i'm killing them all.
14:59:49  <isaacs>gracefully one by one, still
14:59:50  <indutny>SIGINT for master, then
15:00:21  <isaacs>indutny: https://github.com/isaacs/cluster-master/blob/master/cluster-master.js#L182-189
15:00:42  <indutny>oh, interesting
15:00:51  <indutny>so you think it's a user-land thing, right?
15:01:17  <isaacs>well... it'd be nice if we could guarantee that the process exiting always kills them
15:01:25  <isaacs>this doesn't help me if i throw an error or something in the master
15:01:52  * ericktjoined
15:02:01  <indutny>yeah
15:02:16  <indutny>SIGHUP is the only way for that, actually
15:02:31  <indutny>think, master has experienced heap memory overflow
15:03:21  <indutny>isaacs: why should worker restart on SIGHUP?
15:03:37  <indutny>isaacs: how will it get balanced work in?
15:04:06  <indutny>isaacs: aaah, that's only for master
15:04:19  <indutny>isaacs: well, I don't understand your concerns about SIGHUP for workers then
15:09:25  <isaacs>indutny: if you send a sighup to a worker, it should just die or catch it, normally
15:09:44  <isaacs>indutny: the thing is, i'm using sighup with cluster-master like you'd use sighup with nginx or apache
15:09:55  <isaacs>re-read the config file, restart all workers
15:09:55  * toothrjoined
15:10:23  <isaacs>but if the master *dies*, then it'd be nice if that could automatically take out all cluster workers
15:15:25  * AndreasMadsenjoined
15:17:44  * TheJHquit (Read error: Connection timed out)
15:18:13  * TheJHjoined
15:21:01  <AndreasMadsen>Hi I think there is a big memory memory leak in node-windows. I happens when I execute "node test/simple/regress-error-loop.js" one of the processors do a quick jump to 100.000 KB and continues up to 700.000 where it stands (or don't do anythong). URL: https://github.com/AndreasMadsen/immortal/blob/windows-test/test/simple/regress-error-loop.js
15:21:40  <AndreasMadsen>PS: I'm sorry that I can't write a small testcase
15:23:38  <AndreasMadsen>the testcase is set to log a 1 MB error in a daemon processors, and then restart the child group and reset the error buffer when it extend that limit, it works fine on linux and mac - but not on windows.
15:24:01  <AndreasMadsen>And there is no if (process.platform === 'win32') in tested code
15:26:37  <indutny>isaacs: it won't die
15:27:52  <indutny>isaacs: on SIGHUP
15:27:55  <indutny>bnoordhuis: ping pong
15:27:59  <indutny>benvie: ding dong
15:28:01  <indutny>oops ^
15:28:08  <indutny>tab-completion fault
15:28:13  <indutny>bnoordhuis: ding dong
15:28:26  <indutny>bnoordhuis: what about 'vm' patch?
15:28:52  <indutny>isaacs: it'll just ignore it, AFAIK
15:29:04  <indutny>but let me check
15:29:15  <indutny>oh, it dies
15:29:22  <indutny>crap, this is misinformation
15:29:27  <indutny>from #node.js channel
15:30:02  <AndreasMadsen>indutny: a worker will kill itself if it accidently lost the connection with the master in 0.7
15:30:11  <indutny>good
15:30:36  <AndreasMadsen>^ https://github.com/joyent/node/blob/master/lib/cluster.js#L496
15:31:33  <AndreasMadsen>It is very difficult to implement in 0.6
15:33:41  <AndreasMadsen>I wanted to report by bug on joyent/node - but you guys don't take issues if it involves a module, right?
15:34:48  <indutny>AndreasMadsen: well, 0.6 is almost near to be dead
15:34:52  <indutny>0.8 will come soon
15:35:09  <AndreasMadsen>indutny: I know, but 0.4 still lives
15:35:16  <indutny>improving both releases is nearly impossible (in terms of developers hours)
15:35:30  <indutny>AndreasMadsen: that's questionable
15:35:53  <AndreasMadsen>indutny: cloud9 runs on 0.4
15:36:07  <AndreasMadsen>indutny: I know some other people there do too
15:36:15  <indutny>AndreasMadsen: I'm quite sure they'll move to another version eventually, though I don't really know their concerns
15:36:29  <indutny>AndreasMadsen: Nodejitsu and Yandex are using v0.6
15:36:30  <tjfontaine>c9 is supposed to be pushing hard to move beyond .4
15:37:50  <AndreasMadsen>indutny: I can tell that I still get questions about how to update from cluster 0.4 to 0.6, so 0.4 do live. It is not questionable
15:38:08  <indutny>well, some people use PHP 4
15:38:25  <indutny>(I'm not mentioning people who're using PHP 5, instead of node :P )
15:38:55  <indutny>many will blame them, but for many projects porting to new version has more cost than using stable old one
15:39:04  <indutny>i.e. projects that ain't actively maintained
15:39:14  <indutny>(bugfix-only state)
15:40:18  <AndreasMadsen>indutny: and there are those how still develop ActiveX plugins to IE5.5 in Denmark (I won't tell you who)
15:40:36  <indutny>indeed, but how should we consider that?
15:40:58  <indutny>should microsoft add new functionality to IE5.5
15:41:03  <indutny>or should PHP 4 be improved
15:41:05  <AndreasMadsen>Code will never really die
15:41:17  <indutny>I think you forgot what topic caused that discussion :P
15:41:20  <AndreasMadsen>And no we should update it
15:41:22  <indutny>s/that/this
15:41:38  <AndreasMadsen>*And no we shouldn't update it
15:42:22  <AndreasMadsen>indutny: should node 0.6 kill workers when master dies, my answer is no - since 0.7 does it.
15:42:32  <indutny>AndreasMadsen: yeah, that's it
15:42:32  <indutny>:P
15:43:14  <AndreasMadsen>Anyway, can I report memory leak bugs, that I can only reproduce in a module testcase
15:43:20  <AndreasMadsen>?
15:43:52  <AndreasMadsen>^ https://github.com/AndreasMadsen/immortal/blob/windows-test/test/simple/regress-error-loop.js on windows
15:46:10  <AndreasMadsen>Is it normal that libuv becomes extra silent when memory leak on windows is mentioned
15:46:13  <AndreasMadsen>?
15:47:30  <piscisaureus_>AndreasMadsen: can you give me an executive summary?
15:47:32  * theColequit (Quit: theCole)
15:47:46  * stephankjoined
15:48:01  <AndreasMadsen>piscisaureus_: a child creates some stderr output
15:48:06  <indutny>AndreasMadsen: there're few persons here, who can check that :)
15:48:12  <indutny>AndreasMadsen: and I'm not one of them
15:48:39  <AndreasMadsen>.. it is then propergated to another process
15:48:56  <AndreasMadsen>... where stderr from the child is stored
15:49:03  <isaacs>We will continue to support bugs in 0.6 through the end of hte year.
15:49:07  <isaacs>but improving cluster? no.
15:49:19  <isaacs>v0.6 cluster is a proof of concept. it is not ready for prime time until v0.8
15:49:30  <AndreasMadsen>... when it gets to 1MB (the buffer) the child should be force killed and the buffer restarted
15:50:00  <AndreasMadsen>... it works on mac and linux, but on windows it jumps to 100.000 KB and goes up to 700.000 KB where it sands
15:50:08  <AndreasMadsen>s/sands/stands
15:50:47  <AndreasMadsen>This produce the error: https://github.com/AndreasMadsen/immortal/blob/windows-test/test/watchers/monitor.js#L55
15:51:15  <AndreasMadsen>This stores the stderr: https://github.com/AndreasMadsen/immortal/blob/windows-test/lib/executables/daemon.js#L26
15:52:32  <AndreasMadsen>And errorBuffer.length get to about 70000, and then the process uses 700.000 KB
15:53:24  <AndreasMadsen>There is properly no relation between errorBuffer.length === 70000 and 700.000 KB RAM usage
15:57:31  <AndreasMadsen>indutny: I know, but I'm still interested in the policy
16:00:41  * dapjoined
16:02:23  * orlandovftwjoined
16:04:26  * ericktquit (Quit: erickt)
16:06:56  * brsonjoined
16:11:22  * loladiroquit (Ping timeout: 246 seconds)
16:11:51  <isaacs>bnoordhuis: mjr_: This is an interesting clue: https://github.com/Filirom1/node/commit/e25611ead36f06444aa669fbdad33ea5537ff326
16:18:09  * brsonquit (Ping timeout: 276 seconds)
16:18:09  * paddybyersquit (Quit: paddybyers)
16:19:23  * mikealquit (Quit: Leaving.)
16:21:52  * isaacsquit (Remote host closed the connection)
16:23:33  <piscisaureus_>AndreasMadsen: https://gist.github.com/bb0f9e1511deb31009ec
16:23:40  <piscisaureus_>AndreasMadsen: couldn't find any significant leaks
16:23:44  <piscisaureus_>or none at all
16:23:58  <AndreasMadsen>piscisaureus_: neither could I
16:24:02  <AndreasMadsen>v
16:24:46  <AndreasMadsen>piscisaureus_: But there is one, however I can't tell if it is in node, but since there is no if (process.platform === 'win32') I believe so.
16:25:28  <piscisaureus_>AndreasMadsen: sorry, can you rephrase that more carefully?
16:25:34  <AndreasMadsen>sure
16:28:38  <AndreasMadsen>I coudn't fine any issues when I did my quick test (looks alot like yours), but my hypothesis "it is something in node" still stands. This is because there are no "in case of windows" logic in the affected code and it works perfectly on windows. Also the fact that it so quickly jumps to 100.000 KB (before it even generates 10 KB of stderr) seams to confirm that.
16:29:37  <piscisaureus_>AndreasMadsen: 100kb or even 1MB doesn't mean anything
16:30:18  <piscisaureus_>AndreasMadsen: but you if your memory usage keeps going up and up
16:30:31  <piscisaureus_>there is a leak, either in your app logic, or in node
16:31:00  <AndreasMadsen>piscisaureus_: exactly - until it hits 680.000 KB then the gb seams balance it there.
16:31:29  * brsonjoined
16:31:59  <AndreasMadsen>... the process is so busy with gb, that it almost don't do anything.
16:32:16  <AndreasMadsen>s/gb/gc/
16:34:41  * philipsquit (Excess Flood)
16:35:30  <AndreasMadsen>* and it works perfectly on linux and mac.
16:35:46  * mmalecki[away]changed nick to mmalecki
16:36:07  <piscisaureus_>AndreasMadsen: I don't know
16:36:21  <piscisaureus_>AndreasMadsen: I don't really feel for debugging immortal right now
16:36:24  * philipsjoined
16:36:33  <piscisaureus_>AndreasMadsen: the issue could be that some stderr is nonblocking on windows
16:36:43  <bnoordhuis>indutny: pong
16:36:48  <indutny>bnoordhuis: pang
16:36:55  <indutny>bnoordhuis: 'vm' stuff?
16:37:03  <bnoordhuis>can you link me to the patch again?
16:37:04  <piscisaureus_>so if you blast data through it while nobody is reading at the other end your process will blow up
16:37:08  <indutny>bnoordhuis: k
16:37:09  <AndreasMadsen>piscisaureus_: it could be that. How do I debug when I have more that one process?
16:37:24  <indutny>bnoordhuis: https://gist.github.com/4e8b9a3c973e2ef41646
16:38:10  <piscisaureus_>AndreasMadsen: umm, the same way you debug one process. Node has no special tricks for debugging multiple processes.
16:38:22  <bnoordhuis>indutny: right. generally seems okay (would need a test or two) but is there a reason not to throw if !args[0]->IsObject()?
16:38:40  <bnoordhuis>this looks like it's silently ignoring a programmer error
16:38:48  <indutny>bnoordhuis: you're right
16:38:52  <indutny>lets throw a error
16:39:23  <indutny>"createContext() accepts only objects as first argument"
16:39:24  <AndreasMadsen>piscisaureus_: but node debug runs on a port, there will then be double used.
16:39:41  <piscisaureus_>AndreasMadsen: right. Well then it won't work.
16:39:42  <bnoordhuis>indutny: exactly
16:39:51  <indutny>bnoordhuis: ok, should I just land it?
16:39:53  <piscisaureus_>AndreasMadsen: but you don't have to debug it with node debug
16:40:02  <piscisaureus_>AndreasMadsen: I just meant in a more general sense
16:40:02  <indutny>bnoordhuis: \
16:40:10  <indutny>bnoordhuis: sorry, that was a cat
16:40:23  <indutny>bnoordhuis: it's name Marla :P
16:40:25  <indutny>btw
16:40:28  <bnoordhuis>hi marla
16:40:45  <AndreasMadsen>piscisaureus_: Oh I have debuged "in a more general sense" for an hour - it is impossible when the process is so busy with gc.
16:41:02  <bnoordhuis>indutny: make it throw an error, add some regression tests and i'm okay with it
16:41:09  <indutny>bnoordhuis: kk
16:43:46  <piscisaureus_>AndreasMadsen: so when I run regress-error-loop.js I just end up with 3 idle node processes
16:43:52  <piscisaureus_>AndreasMadsen: not seeing any leakage
16:45:07  <piscisaureus_>AndreasMadsen: but the processes are idle so supposedly something is not working about that test
16:45:25  <AndreasMadsen>piscisaureus_: Oh, wow - that sounds strange (like I don't know what to say)
16:45:50  <AndreasMadsen>piscisaureus_: they should be petty idle
16:47:42  * perezdjoined
16:50:00  <piscisaureus_>AndreasMadsen: http://screencast.com/t/m8zfZcGHiccO
16:51:40  <AndreasMadsen>piscisaureus_: hmm, sec
16:54:49  <AndreasMadsen>piscisaureus_: nop same issues
16:55:33  * AvianFlujoined
16:58:33  * theColejoined
17:01:41  * ericktjoined
17:03:00  * mikealjoined
17:03:26  * paddybyersjoined
17:06:02  * avsejquit (Quit: Quit)
17:07:25  * avsejjoined
17:08:41  * orlandovftwquit (Ping timeout: 255 seconds)
17:11:36  * theColequit (Quit: theCole)
17:12:29  * paddybyersquit (Quit: paddybyers)
17:12:59  <AndreasMadsen>piscisaureus_: not that it really helps, but here is mine http://www.screencast.com/t/s3036TMYkuMQ
17:14:33  * theColejoined
17:14:34  * AndreasMadsenwill go an eat
17:27:30  * isaacsjoined
17:27:42  * TooTallNatejoined
17:32:58  * `3rdEdenjoined
17:34:42  * ericktquit (Quit: erickt)
17:38:50  * ericktjoined
17:39:12  * ericktquit (Client Quit)
17:40:13  * paddybyersjoined
17:51:04  <piscisaureus_>bnoordhuis:
17:51:05  <piscisaureus_>Linux accept() (and accept4()) passes already-pending network errors on the new socket as an error code from accept(). This behavior differs from other BSD socket implementations. For reliable operation the application should detect the network errors defined for the protocol after accept() and treat them like EAGAIN by retrying. In case of TCP/IP these are ENETDOWN, EPROTO, ENOPROTOOPT, EHOSTDOWN, ENONET, EHOSTUNREACH, EOPNOTSUPP, an
17:51:09  <piscisaureus_>does libuv do that?
17:59:20  * orlandovftwjoined
18:00:36  * c4milochanged nick to c4milo|lunch
18:05:38  * mikealquit (Quit: Leaving.)
18:07:21  * mikealjoined
18:15:31  * ericktjoined
18:16:40  * piscisaureus__joined
18:18:00  * piscisaureus_quit (Ping timeout: 248 seconds)
18:23:37  * mikealquit (Quit: Leaving.)
18:31:14  <mjr_>isaacs: that is interesting. Did bmc show you his core file magic?
18:41:34  * isaacsquit (Remote host closed the connection)
18:42:34  * piscisaureus__quit (Ping timeout: 246 seconds)
18:42:47  * isaacsjoined
18:42:50  * piscisaureus__joined
18:43:31  * piscisaureus__changed nick to piscisaureus_
18:48:51  * hij1nxjoined
18:49:57  * c4milo|lunchchanged nick to c4milo
18:51:03  <TooTallNate>should `process.title` setting throw on OS X?
18:51:18  <piscisaureus_>that seems odd
18:51:21  <TooTallNate>or.... can we just implement it :D
18:51:43  <piscisaureus_>I think we had it for a while
18:51:48  <piscisaureus_>Rasmus Andersson did it
18:54:58  <TooTallNate>lulz
18:54:59  <TooTallNate>http://stackoverflow.com/questions/4217947/setting-process-name-on-mac-os-x-at-runtime
18:55:00  <isaacs>mjr_: yeah, he showed me some stuff.
18:55:03  <TooTallNate>it's all a big circle
18:55:14  <isaacs>mjr_: spoiler: there's a lot of buffers ;)
18:55:19  <mjr_>Yeah, lots.
18:55:25  <isaacs>mjr_: but that doesnt' explain why the buffers aren't getting cleaned up normally
18:55:40  <isaacs>mjr_: my suspicion is that we're leaking response objects, or leaking parsers, or both
18:55:53  <isaacs>mjr_: if i give you a patch, how hard is it to test out?
18:55:56  <piscisaureus_>stackoverflow.com/questions/10399074/php-decrypt-passwords-from-user-cd
18:56:28  <tjfontaine>oh dear lord
18:58:02  <mmalecki>isaacs: that'd be likely. we're observing some leaks in our balancers but nothing weird appears on the heap snapshot
18:59:27  * piscisaureus__joined
19:00:39  * piscisaureus_quit (Ping timeout: 276 seconds)
19:01:21  <indutny>bnoordhuis: pushing
19:01:29  <CIA-155>node: Fedor Indutny master * r9f9c333 / (src/node_script.cc test/simple/test-vm-create-context-arg.js):
19:01:29  <CIA-155>node: vm: accept only object as arg of .createContext()
19:01:29  <CIA-155>node: Converting strings and others to objects is very slow and essentially
19:01:29  <CIA-155>node: wrong. - http://git.io/-oD8WA
19:02:33  <mjr_>isaacs: very easy to run a test patch
19:02:52  <mjr_>We are already floating two patches, one for no idle and the other to fix a parser free bug
19:05:30  <indutny>bnoordhuis: reviewing your 'walk' branch
19:06:27  * mikealjoined
19:09:40  <indutny>bnoordhuis: lgtm
19:09:46  <indutny>bnoordhuis: with small questions
19:10:05  <indutny>bnoordhuis: https://github.com/bnoordhuis/node/compare/issue3180#L9R1351 may be better push ".owner" property to this resulting list?
19:10:16  <indutny>bnoordhuis: handles are not really public to users
19:10:24  <indutny>bnoordhuis: otherwise looks good to me
19:14:45  <indutny>bnoordhuis: ok, time to sleep
19:14:47  <indutny>ttyl, guys
19:38:26  * hij1nxquit (Quit: hij1nx)
19:49:07  * AndreasMadsenquit (Remote host closed the connection)
19:56:03  * `3rdEdenquit (Quit: Leaving...)
19:56:15  * theColequit (Quit: theCole)
19:57:04  * mikealquit (Quit: Leaving.)
19:57:13  * c4milochanged nick to c4milo|bbl
20:02:21  * theColejoined
20:11:01  <piscisaureus__>igorzi: re junction vs symlink ... I don't really think it matters which default we pick
20:11:11  <piscisaureus__>igorzi: at least, not for node
20:11:26  <piscisaureus__>igorzi: we can decide that later, first libuv needs to support both
20:13:18  * ryah_waves
20:13:42  * indutnywaves
20:13:49  * piscisaureus__waves
20:13:53  * piscisaureus__changed nick to piscisaureus
20:14:26  * `3rdEdenjoined
20:15:14  <indutny>ttyl, guys :P
20:15:20  <indutny>definitely going to sleep now
20:15:24  * indutnywaves again
20:15:32  <piscisaureus>indutny: sleep well. I know the feeling
20:21:46  * irajoined
20:22:27  * mralephquit (Quit: Leaving.)
20:30:48  <isaacs>ryah_: hola
20:32:12  <CIA-155>node: isaacs v0.6 * racf1950 / src/node_version.h : Now working on 0.6.17 - http://git.io/pdDnmA
20:32:22  * paddybyersquit (Ping timeout: 249 seconds)
20:32:46  <isaacs>whoops, forgot to push that yesterday
20:32:51  <isaacs>*^_^*
20:32:53  * perezdquit (Read error: Connection reset by peer)
20:33:09  * perezdjoined
20:33:20  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
20:38:27  <isaacs>TooTallNate: Hey, 248f552 broke test/simple/test-process-exit.js
20:39:04  <TooTallNate>uhhh.. how so?
20:39:04  <isaacs>TooTallNate: which is weird, since i see that the commit touched that file...
20:39:09  <isaacs>well, it's calling it recursively
20:39:15  <isaacs>assert.equal(nexits++, 0);
20:39:18  <isaacs>that's hitting more than once
20:39:35  <TooTallNate>"exit" should only be emitted once
20:39:38  <isaacs>yeah
20:39:40  <isaacs>it's not :)
20:39:47  <TooTallNate>ok, lemme check
20:39:54  <TooTallNate>i swear it was passing when i committed it :\
20:40:21  <isaacs>https://gist.github.com/2571183
20:40:48  <isaacs>thanks :)
20:41:16  <isaacs>simple/test-cluster-worker-death looks like it's failing now, too
20:41:30  <TooTallNate>i saw an issue about that
20:41:31  <isaacs>https://gist.github.com/2571193
20:43:17  <TooTallNate>isaacs: https://github.com/joyent/node/issues/3198
20:44:55  * mikealjoined
20:47:45  * hij1nxjoined
20:48:05  * loladirojoined
20:49:23  <isaacs>TooTallNate: thanks for the link. commented.
20:50:19  <TooTallNate>isaacs: well it's a good thing my adjusted test case exposed our bug :D
20:50:29  <TooTallNate>we're not setting the "exiting" var
20:50:34  <TooTallNate>during a "natural" exit
20:50:38  <TooTallNate>patch coming
20:51:06  * dapquit (Quit: Leaving.)
20:51:36  * dapjoined
20:52:30  <isaacs>TooTallNate: w00t!
20:52:31  <isaacs>:)
20:52:46  <isaacs>TooTallNate: oh, so it was always a bug, we just didn't catch it before?
20:52:54  * hij1nxquit (Quit: hij1nx)
20:52:56  <TooTallNate>yup :) try it on 0.6.16
20:53:30  <TooTallNate>isaacs: https://gist.github.com/d84b7947da0932ae6fe2 <-- gets called twice
20:55:17  <TooTallNate>isaacs: https://github.com/TooTallNate/node/commit/fix-exit-double-event
20:55:49  <TooTallNate>so i guess it could go into v0.6 if we care
20:56:02  * hij1nxjoined
20:58:03  <isaacs>TooTallNate: we do not care :)
20:58:16  <isaacs>TooTallNate: multiple exit events are not super terrible.
20:58:43  <TooTallNate>and it only happens at most twice
20:58:59  <TooTallNate>so you can't overflow the stack at least :p
21:02:08  * perezdquit (Quit: perezd)
21:02:42  <TooTallNate>isaacs: looks good?
21:03:47  <isaacs>TooTallNate: tests pass otherwise?
21:03:53  <isaacs>code change is pretty uncontroversial.
21:04:13  <TooTallNate>well it fixes the broken one :D
21:04:18  <TooTallNate>but ya i think it's good
21:04:28  <TooTallNate>i'll do a quick `make test` to be sure
21:05:56  <TooTallNate>isaacs: actually i'll just remove the initial `process._exiting = false` call
21:06:01  * skomskijoined
21:06:03  <TooTallNate>don't pollute `process` unnecessarily :D
21:06:08  <isaacs>yeah
21:06:15  <isaacs>undefined is falsey :)
21:06:19  <TooTallNate>indeed
21:07:53  * mikealquit (Ping timeout: 250 seconds)
21:08:22  * loladiroquit (Quit: loladiro)
21:09:14  * paddybyersjoined
21:15:21  <TooTallNate>ok tests are good
21:15:25  * erickt_joined
21:15:28  <TooTallNate>3 failures, but unrelated to exit
21:15:30  <TooTallNate>pushing...
21:16:06  <CIA-155>node: Nathan Rajlich master * rb894521 / (src/node.cc src/node.js):
21:16:06  <CIA-155>node: process: ensure that "exit" doesn't get emitted twice on a natural exit
21:16:06  <CIA-155>node: Fixes "test/simple/test-process-exit.js". - http://git.io/e6Vgqg
21:17:57  * ericktquit (Ping timeout: 260 seconds)
21:17:57  * erickt_changed nick to erickt
21:18:24  * theColequit (Quit: theCole)
21:24:59  * skomskiquit (Ping timeout: 260 seconds)
21:27:53  <CIA-155>node: isaacs http-memleak * rbfe9cdb / lib/http.js :
21:27:53  <CIA-155>node: Null references to request object on socket errors.
21:27:53  <CIA-155>node: Regarding #3199 and #3179 and issues seen in production.
21:27:53  <CIA-155>node: Hopefully this fixes them. - http://git.io/71OXrw
21:28:20  <isaacs>mjr_: Hey
21:28:33  <isaacs>mjr_: how hard would it be to get you to test out bfe9cdb7f2f9b90c95a221dcdce29263f0da5c75?
21:29:36  <isaacs>mjr_: this fixes the tests that a few others have set up that look kinda like your issue.
21:30:11  <mjr_>Looking
21:34:25  * c4milo|bblchanged nick to c4milo
21:34:36  <mjr_>isaacs: do you know about the patches that we are floating?
21:34:52  <isaacs>mjr_: not offhand, is there a branch or something somewhere?
21:35:08  <isaacs>mjr_: this should apply clean on v0.6 or master
21:35:31  <mjr_>here is what we are running rich tnow
21:35:33  <mjr_>right now
21:35:34  <mjr_>https://github.com/Voxer/node/commits/v0.6
21:36:12  <mjr_>This is the commit that forces no idle all the time, which is how we run now
21:36:13  <mjr_>https://github.com/Voxer/node/commit/91199c724e72d49fd9a3d7979a04162481581eeb
21:36:22  <isaacs>mjr_: you ought to try merging in 0.6.16 at some point, but it's not urgent, i don't think
21:36:28  <isaacs>you have most of the more important fixes in it
21:36:33  <mjr_>But it also notable changes this one line in http.js:
21:36:37  <mjr_>+ parser.socket.ondata = parser.socket.onend = null;
21:36:38  <mjr_>1130 1132
21:37:12  <mjr_>Without that line, we crash all the time with can't call execute of undefined.
21:37:24  <mjr_>Like, all the damn time.
21:37:41  * skmpyjoined
21:37:58  <isaacs>weird
21:38:09  <mjr_>Need to step away briefly for lunch, but I'll be back soon to hopefully talk more about this.
21:38:11  <isaacs>mjr_: wanna send upstream?
21:38:14  <isaacs>yeah, suresure
21:41:43  * skmpychanged nick to bromancer
21:41:56  * bromancerchanged nick to skmpy
21:42:44  * dapquit (Quit: Leaving.)
21:43:15  * dapjoined
21:52:13  * mikealjoined
21:53:07  * bulatshakirzyanoquit (Quit: Computer has gone to sleep.)
22:02:37  <mjr_>isaacs: I can send that upstream if you think that's a good fix.
22:05:59  * rendarquit
22:07:54  * igorzi_joined
22:09:49  <isaacs>mjr_: yeah, i'm testing it out now on that branch
22:09:59  <isaacs>seems to work
22:10:12  <mjr_>I don't know how to reproduce the issue that it fixes though.
22:10:16  <isaacs>this is what i'm doing:
22:10:18  <isaacs>diff --git a/lib/http.js b/lib/http.js
22:10:18  <isaacs>index 3986709..9aaff7f 100644
22:10:18  <isaacs>--- a/lib/http.js
22:10:19  <kohai>diff has -1 beer
22:10:19  <isaacs>+++ b/lib/http.js
22:10:22  <isaacs>@@ -1128,6 +1128,9 @@ ClientRequest.prototype.onSocket = function(socket) {
22:10:24  <isaacs> var freeParser = function() {
22:10:25  <isaacs> if (parser) {
22:10:28  <isaacs> parsers.free(parser);
22:10:30  <isaacs>+ parser.socket.onend = null;
22:10:31  <isaacs>+ parser.socket.ondata = null;
22:10:33  <isaacs>+ parser.socket = null;
22:10:36  <isaacs> parser = null;
22:10:38  <isaacs> }
22:10:39  <isaacs> };
22:10:42  <isaacs>diff never pays his tab.
22:10:44  <mjr_>diff, careful with all of those beers.
22:10:44  <isaacs>diff --
22:10:44  <kohai>diff has -2 beers
22:10:53  <isaacs>mjr_: those are beers diff owes me
22:11:57  <mjr_>I'm confused as to why any of this would leak.
22:12:10  <isaacs>mjr_: req -> event handlers -> parser/socket -> req.
22:12:18  <mjr_>But what holds req?
22:12:24  <isaacs>the socket
22:12:37  <mjr_>Because we re-cycle the socket sometimes?
22:12:46  <isaacs>oh, ok, so, no, the issue is that we're recycling the parser.
22:13:08  <isaacs>and we can't give up the freelist thingie, because making parsers is expensive.
22:13:09  <mjr_>Oh, OK. We must be keeping something around for this reference to be anchored to.
22:13:14  <isaacs>right
22:13:25  <isaacs>if you throw out the freelist bs, the problem goes away, but we lost performance
22:13:37  <mjr_>I'm quite fond of performance.
22:13:38  <isaacs>if you do req.removeAllListeners(), then the problem goes away, but that's dumb.
22:13:45  <isaacs>yes, we are all fond of performance :)
22:14:33  <mjr_>OK, I'll merge this in and see if it helps.
22:14:43  <mjr_>We'll know in a few hours.
22:26:16  <isaacs>mjr_: awesome
22:26:45  <mjr_>isaacs: do you know if we still need to do this:
22:26:46  <mjr_>https://gist.github.com/2571958
22:26:53  <mjr_>And / or if it might be related to this leak?
22:26:54  <CIA-155>node: isaacs http-memleak * rbce6813 / lib/http.js : http: Remove socket ondata/onend in parser cleanup - http://git.io/y_xUdg
22:27:32  <isaacs>mjr_: that doesn't look very intelligible to me..
22:27:35  <mjr_>This was to deal with a case where https requests would be closed and then linger.
22:27:39  <isaacs>right
22:27:56  <isaacs>mjr_: i'd try without it and with it, and see which is better :)
22:28:10  <isaacs>mjr_: but, that patch shouldn't have any *harmful* effect with this additional change.
22:28:21  <mjr_>So we reached inside and added that req.socket thing.
22:28:21  <isaacs>mjr_: so, i'd try to leave it as-is for nwo
22:28:38  <mjr_>Just wondering if that might be related, and could perhaps explain why we are seeing this and nobody else is.
22:29:18  <isaacs>mjr_: well, others *ARE* seeing it.
22:29:22  <isaacs>mjr_: just a lot less than you are.
22:29:26  <mjr_>ahh, good
22:29:29  <mjr_>And by good, I mean bad.
22:29:33  <mjr_>The good kind of bad.
22:29:39  <isaacs>because most people's servers talk to web browsers, which don't randomly kill connections when they go into elevators.
22:29:58  <isaacs>so, this socket error code path is much more rare
22:30:29  <mjr_>OK, I'm going to leave it. I guess I should make that error listener log something and see if it ever shows up before removing it.
22:32:02  * ggreerquit (Ping timeout: 260 seconds)
22:32:39  * avalanche123quit (Ping timeout: 244 seconds)
22:34:18  * avalanche123joined
22:41:31  * AngryParsleyjoined
22:41:48  * AngryParsleychanged nick to ggreer
22:41:55  <mjr_>isaacs: for reference, there's an open issue on the parser free thing: https://github.com/joyent/node/issues/2997
22:45:45  * avsej_joined
22:45:56  * avsejquit (Excess Flood)
22:46:06  <mjr_>isaacs: and also, this issue is causing some terrible things to happen, which I think include data corruption: https://github.com/joyent/node/issues/3176
22:52:16  <CIA-155>node: isaacs master * rfb400b4 / lib/tty.js : Return after emitting error in tty.js - http://git.io/oihdLg
22:53:08  * mikeal1joined
22:57:15  * toothrquit (*.net *.split)
22:57:16  * russell_hquit (*.net *.split)
22:57:16  * mikealquit (*.net *.split)
22:57:16  * ericktquit (*.net *.split)
22:57:16  * TooTallNatequit (*.net *.split)
22:57:16  * AvianFluquit (*.net *.split)
22:57:17  * mjr_quit (*.net *.split)
22:57:17  * ryah_quit (*.net *.split)
22:57:17  * kohaiquit (*.net *.split)
22:57:18  * TheJHquit (*.net *.split)
22:57:18  * bnoordhuisquit (*.net *.split)
22:57:18  * chiltsquit (*.net *.split)
22:57:18  * dapquit (*.net *.split)
22:57:19  * saghulquit (*.net *.split)
22:57:19  * isaacsquit (*.net *.split)
22:57:19  * tjfontainequit (*.net *.split)
22:57:20  * elijah-mbpquit (*.net *.split)
22:57:20  * DrPizzaquit (*.net *.split)
22:57:20  * igorzi_quit (*.net *.split)
22:57:20  * igorziquit (*.net *.split)
23:01:14  * TooTallNatejoined
23:01:15  * AvianFlujoined
23:01:15  * toothrjoined
23:01:15  * bnoordhuisjoined
23:01:15  * igorzijoined
23:01:15  * russell_hjoined
23:01:15  * mjr_joined
23:01:15  * ryah_joined
23:01:15  * chiltsjoined
23:01:15  * kohaijoined
23:02:04  * dapjoined
23:02:04  * saghuljoined
23:02:06  * ggreerquit (Changing host)
23:02:06  * ggreerjoined
23:02:37  * isaacsjoined
23:02:38  * tjfontainejoined
23:02:38  * elijah-mbpjoined
23:02:38  * DrPizzajoined
23:04:47  * isaacsquit (Remote host closed the connection)
23:05:11  * isaacsjoined
23:17:41  * dshaw_joined
23:17:45  * dshaw_quit (Client Quit)
23:24:48  * dap1joined
23:27:24  * saghul_joined
23:31:55  * bnoordhuisis back
23:33:15  * dapquit (*.net *.split)
23:33:16  * saghulquit (*.net *.split)
23:33:18  * saghul_changed nick to saghul
23:35:32  * hij1nxquit (Quit: hij1nx)
23:35:53  <bnoordhuis>indutny: https://github.com/bnoordhuis/node/compare/issue3180#L9R1351 may be better push ".owner" property to this resulting list? <- yes, but not everything has an owner (timers)
23:36:10  * mikeal1quit (Quit: Leaving.)
23:36:51  * dshaw_joined
23:43:05  * c4milo_joined
23:44:35  * mikealjoined
23:45:30  * txdv_joined
23:47:27  * demarchi_joined
23:48:25  * zz_jcejoined
23:51:11  * creationix_joined
23:51:33  * c4miloquit (Read error: Connection reset by peer)
23:51:34  * ircretaryquit (Ping timeout: 272 seconds)
23:51:34  * txdvquit (Ping timeout: 272 seconds)
23:51:34  * creationixquit (Ping timeout: 272 seconds)
23:51:34  * demarchiquit (Ping timeout: 272 seconds)
23:51:35  * jcequit (Ping timeout: 272 seconds)
23:51:35  * creationix_changed nick to creationix
23:52:32  * c4milo_quit (Ping timeout: 276 seconds)
23:54:57  * brsonquit (Read error: Operation timed out)
23:58:02  * brsonjoined