00:03:05  <piscisaureus>hmm
00:03:14  <piscisaureus>igorzi: it is very difficult to get a list
00:03:29  <piscisaureus>igorzi: I like DrPizza's idea, let's put it in a spreadsheet
00:03:37  <piscisaureus>and annotate
00:03:44  <DrPizza>parsing teh output is a fucking pain, however
00:04:11  <piscisaureus>yes
00:04:19  <piscisaureus>I can do that
00:04:52  <piscisaureus>the os.unlink() errors are also PITA
00:05:05  <DrPizza>man are we still getting them
00:05:12  <DrPizza>we need to tell pythont o enable sharing mode too, I guess
00:05:18  <piscisaureus>yes, loads
00:12:33  <bnoordhuis>[17:52|% 100|+ 533|- 27]: Done <- linux :/
00:12:40  <bnoordhuis>seems a lot slower too
00:12:46  <bnoordhuis>it usually takes 10-12 minutes
00:22:51  <igorzi>there are also 4 libuv tests failing.. we should probably fix these first?
00:23:32  <piscisaureus>that might help :-)
00:23:52  <piscisaureus>I've ran all tests, now compiling a sheet
00:28:02  * graydonquit (Quit: Leaving.)
00:33:59  <indutny>good evening, everyone
00:40:53  <igorzi>bnoordhuis: piscisaureus: on unix uv_fs_t.errorno is a uv error? (error from eio translated into uv)"\
00:41:03  <igorzi>?
00:41:05  <bnoordhuis>igorzi: yes
00:41:06  <piscisaureus>igorzi: yes
00:42:28  <igorzi>ok, i see that it's also that on windows now
00:44:03  <bnoordhuis>[14:11|% 100|+ 530|- 30]: Done <- sunos
00:45:12  <dmkbot>joyent/node: Shahor: hash.update fails on second call (https://github.com/joyent/node/issues/749 Seen) - https://github.com/joyent/node/issues/1415
00:51:42  <igorzi>bnoordhuis: piscisaureus: actually, i'm wrong.. on windows uv_fs_t.errorno is still set directly to CRT errno
00:52:09  <piscisaureus>igorzi: we have no crt_errno -> uv_errno mapping yet :-/
00:52:29  <piscisaureus>igorzi: although I'm not sure we'll need it
00:52:46  <piscisaureus>maybe you can use _doserrno and map that using uv_set_sys_error?
00:53:32  <igorzi>hmm, that might be a good idea
00:54:51  <igorzi>let's do that.. maybe we can get away with just one mapping
00:59:52  <piscisaureus>igorzi: bnoordhuis: ryah: so what do you prefer, office 365 or google docs?
01:00:09  <bnoordhuis>piscisaureus: google docs
01:00:15  <bnoordhuis>sorry igorzi
01:01:57  * felixgequit (Quit: felixge)
01:02:24  <DrPizza>lol
01:02:36  <piscisaureus>I was hoping to unleash a fight
01:02:53  <DrPizza>I'd rather use xl
01:05:26  <piscisaureus>https://docs.google.com/spreadsheet/ccc?key=0AncAtEVJvlbUdFR0MXhFNGlLYl9XeVBGckRBeUlPbUE&hl=nl
01:06:32  <piscisaureus>bnoordhuis: igorzi: DrPizza: ryah: if you have a gmail account I can give you write access
01:06:43  <DrPizza>[email protected]
01:06:55  <bnoordhuis>[email protected]
01:09:34  <igorzi>[email protected]
01:11:29  * ericktquit (Quit: erickt)
01:13:14  <DrPizza>piscisaureus: would be be a big pain in the ass to add the pass/fail status of 0.5.5 too, as a baseline?
01:13:30  <piscisaureus>DrPizza: no, can do
01:13:34  <piscisaureus>will take a while
01:13:49  <DrPizza>might be useful to see which new failures and new passes we have
01:14:26  <piscisaureus>DrPizza: yes, but I'll have to make the script more advanced :-)
01:14:34  <DrPizza>ah
01:14:35  <DrPizza>heh
01:16:21  <piscisaureus>I am especially worried about all the read UNKNOWN errors
01:16:27  <piscisaureus>the others seem to be not so bad
01:19:57  <DrPizza>yes, although I'm assuming/hoping they have a common root cause
01:20:01  <DrPizza>and so will all go away together
01:21:52  <piscisaureus>its prolly not worth updating the script now
01:22:20  <piscisaureus>we should mark tests that need to be looked at real soon
01:23:40  <CIA-52>libuv: Igor Zinkovsky master * rcfa1423 / (src/uv-common.h src/win/error.c src/win/fs.c test/test-fs.c): fix fs_file_noent on windows - http://git.io/CmLRIg
01:24:21  <piscisaureus>bnoordhuis: does test-child-process-double-pipe pass on unix?
01:24:21  <igorzi>^----- this does the _doserrno translation
01:24:47  <bnoordhuis>piscisaureus: yes
01:25:12  <dmkbot>joyent/node: dhx71: chunked & keep-alive - https://github.com/joyent/node/issues/940
01:26:50  <igorzi>gtg.. i'll be online later
01:27:07  <piscisaureus>ok
01:40:48  <piscisaureus>hmm
01:41:25  <piscisaureus>all those "read unknown" errors seem to be coming from a situation where pRtlNtStatusToDosError can't map the NTSTATUS to an errno
01:41:27  <piscisaureus>weird
02:05:52  <piscisaureus>aha!
02:06:00  <piscisaureus>it's a windows bug
02:09:07  <piscisaureus>NTSTATUS_FROM_WIN32 mapping: ntstatus = (0xc0070000 | win32_error)
02:09:07  <piscisaureus>RtlNtStatusToDosError: if ((ntstatus & 0xffff0000) == 0x80070000) { it's mapped } else { it's a real ntstatus }
02:09:30  * brsonquit (Ping timeout: 258 seconds)
02:09:40  <piscisaureus>that bug was in win2k, it's still there in 7
02:13:21  <piscisaureus>igorzi: file a bug report :-)
02:14:21  <igorzi>it should get translated to ERROR_BROKEN_PIPE?
02:14:30  <piscisaureus>yes
02:14:37  <igorzi>what's the NTSTATUS?
02:14:51  <piscisaureus>*shrug* I don't know
02:14:57  <piscisaureus>oh - wait
02:15:16  <piscisaureus>igorzi: this is how it works: we update the overlapped.Internal in some cases
02:15:36  <piscisaureus>so we generate a NTStatus from GetLastError with the NTSTATUS_FROM_WIN32 macro
02:15:55  <piscisaureus>so that RtlNtStatusToDosError correctly maps it back for us
02:16:01  <piscisaureus>but the NTSTATUS_FROM_WIN32 is wrong!
02:16:20  <piscisaureus>(that macro comes from the ddk btw)
02:16:40  <piscisaureus>because it effectively does: ntstatus = (0xc0070000 | win32_error)
02:17:04  <piscisaureus>but RtlNtStatusToDosError only maps it back correctly if it would have been: ntstatus = (0x80070000 | win32_error)
02:18:08  <piscisaureus>I can easily fix the macro
02:19:08  <igorzi>ok.. so any GetLastError converted to NTSTATUS (using NTSTATUS_FROM_WIN32) and then back to win32 error (using RtlNtStatusToDosError) would run into this?
02:19:20  <piscisaureus>yes
02:19:47  <piscisaureus>igorzi: although - for sockets we have a special path
02:19:52  <piscisaureus>so socket errors won't see it
02:20:13  <igorzi>ok, so you'll define your own NTSTATUS_FROM_WIN32?
02:20:25  <piscisaureus>Yes
02:20:44  <piscisaureus>#define NTSTATUS_FROM_WIN32(error) ((NTSTATUS) (error) <= 0 ? \
02:20:45  <piscisaureus> ((NTSTATUS) (error)) : ((NTSTATUS) (((error) & 0x0000FFFF) | \
02:20:45  <piscisaureus> (FACILITY_NTWIN32 << 16) | ERROR_SEVERITY_ERROR)))
02:20:55  <piscisaureus>change severity_error into severity_warning
02:20:57  <piscisaureus>then it's correct
02:22:01  <piscisaureus>yes, works :))
02:23:13  <igorzi>how many tests does that fix? :)
02:23:21  <piscisaureus>dunno yet
02:23:24  <piscisaureus>let's see
02:24:11  * piscisaureusrunning them now
02:35:12  <dmkbot>joyent/node: tshinnic: add positioned writing feature to fs.WriteStream - https://github.com/joyent/node/issues/1645
02:39:53  <CIA-52>libuv: Bert Belder master * r12e689d / src/win/winapi.h : win: the ddk got the NTSTATUS_FROM_WIN32 wrong - http://git.io/6IoQXA
02:46:18  <piscisaureus>igorzi: added a column in the sheet
02:48:56  * ericktjoined
02:52:12  <piscisaureus>I am now looking at [19:03|% 100|+ 237|- 42] again :-)
02:52:12  <bnoordhuis>okay, off to bed
02:52:16  <bnoordhuis>you should too, piscisaureus
02:52:24  <piscisaureus>yes
02:52:47  <piscisaureus>bnoordhuis: how is linux looking? made any progress?
02:53:11  <bnoordhuis>piscisaureus: a little
02:53:19  <bnoordhuis>that is, i know why some tests are failing
02:53:26  <bnoordhuis>now to fix them
03:03:28  * bnoordhuisquit (Ping timeout: 245 seconds)
03:12:52  <igorzi>piscisaureus: what does a x in 0.5.6 column mean?
03:13:13  <piscisaureus>igorzi: those where the tests that I thought we should look at before 0.5.6
03:14:13  <piscisaureus>igorzi: not necessarily fix them
03:14:33  <piscisaureus>igorzi: but rather, looking the other tests is pointless in the beginning
03:14:47  <igorzi>ok
03:15:12  <dmkbot>joyent/node: Shahor: hash.update fails on second call (https://github.com/joyent/node/issues/749 Seen) - https://github.com/joyent/node/issues/1415
03:20:59  <igorzi>piscisaureus: i'm fixing test-fs-chmod
03:23:17  <CIA-52>libuv: Bert Belder master * re95a29e / src/win/error.c : Add mapping for ECONNABORTED - http://git.io/osQb-g
03:24:04  <piscisaureus>igorzi: that's nice +1
03:24:04  <piscisaureus>but don't over-work yourself
03:24:07  <piscisaureus>I am checking out too
03:24:31  <piscisaureus>it's only node - it can wait
03:28:42  <igorzi>ok, i'll update the spreadsheet if anything changes
03:33:30  * piscisaureuspart
03:38:11  * piscisaureusjoined
04:02:21  * isaacsquit (Quit: isaacs)
04:17:55  * piscisaureusquit (Ping timeout: 258 seconds)
04:25:12  <dmkbot>joyent/node: tshinnic: unguarded fs.watchFile cache statWatchers checking fixed - https://github.com/joyent/node/issues/1637
04:38:35  * isaacsjoined
04:56:00  * isaacsquit (Quit: isaacs)
04:56:59  * isaacsjoined
05:03:24  * ericktquit (Quit: erickt)
05:49:05  * isaacsquit (Quit: isaacs)
06:25:11  <dmkbot>joyent/node: tshinnic: add positioned writing feature to fs.WriteStream - https://github.com/joyent/node/issues/1645
06:30:28  <igorzi>ryah: https://github.com/igorzi/node/commit/3cbf532c83811f5892378a1f9d5048b3c2bfaa73
06:30:43  <igorzi>fixes test-fs-chmod test
06:31:04  * mralephjoined
06:41:03  <DrPizza>I don't quit eunderstand that test
06:41:20  <DrPizza>why is the assertion different between the two platforms?
07:20:15  * mralephquit (Quit: Leaving.)
07:31:11  <igorzi>because chmod on windows only looks at read-only bit in mode (so we only verify that the read-only bit got set or reset)
08:12:57  <DrPizza>yes I getthat
08:13:09  <DrPizza>but that doesn't explain it
08:13:58  <DrPizza>why is fstat returning bad data on windows?
08:14:51  <DrPizza>the mode returned by fstat should surely beidentical to the mode set by chmod
08:15:18  <DrPizza>so either 0600 or 0400 depending on whether the file is writable or not
08:40:12  <dmkbot>joyent/node: Nais: createContext/runInXXContext : "this" does not refer to the correct object - https://github.com/joyent/node/issues/1674
08:58:20  * dmkbotquit (Remote host closed the connection)
08:58:40  * dmkbotjoined
10:23:37  <dmkbot>joyent/node: Grepsy: Process always exits with exit code 0 - https://github.com/joyent/node/issues/1675
12:01:03  * piscisaureusjoined
12:04:07  * bnoordhuisjoined
12:46:00  <CIA-52>node: Igor Zinkovsky master * r85357ab / test/simple/test-fs-chmod.js : fix test-fs-chmod test - http://git.io/wI0wsg
12:47:46  <bnoordhuis>^ is that a good idea?
12:48:22  <bnoordhuis>piscisaureus: ^
12:48:35  <piscisaureus>bnoordhuis: yes
12:48:39  <piscisaureus>bnoordhuis: why not?
12:49:00  <bnoordhuis>special casing for platforms... feels icky
12:49:13  <bnoordhuis>that's what libuv is supposed to do
12:49:19  <piscisaureus>bnoordhuis: on windows chmod can only do so much
12:49:40  <piscisaureus>bnoordhuis: we can't verify the r and x bits in a file mode, because windows doesn't support that
12:49:50  <piscisaureus>it supports only the w bit
12:49:55  <piscisaureus>there's no way around that
12:49:59  <bnoordhuis>okay
12:52:35  <piscisaureus>bnoordhuis: does unix have struct sockaddr_storage?
12:53:10  <piscisaureus>bnoordhuis: reading the sock/peername into a struct sockaddr fails with EFAULT because struct sockaddr is not big enough
12:55:59  <piscisaureus>bnoordhuis: also, is the family stored in struct sockaddr_storage.ss_family?
13:06:13  <CIA-52>node: Bert Belder master * rf810998 / src/tcp_wrap.cc : net_uv: use sufficient buffer to read sock/peername - http://git.io/zr3-IA
13:06:13  <CIA-52>node: Bert Belder master * rb5db076 / lib/net_uv.js : net_uv: fix 'set is undefined' error - http://git.io/zNe0Og
13:06:13  <CIA-52>node: Bert Belder master * r97cf216 / (5 files in 3 dirs): Upgrade libuv to e95a29ee18 - http://git.io/SiiqkQ
13:11:44  <piscisaureus>bnoordhuis: https://github.com/joyent/node/blob/master/test/simple/test-tls-peer-certificate.js#L44-54
13:12:10  <piscisaureus>bnoordhuis: this fails on windows with ECONNABORTED because the server shuts down. I wonder why this does not fail on unix.
13:13:06  <piscisaureus>hmm. maybe it's not the server that shuts down that is the problem
13:24:28  <DrPizza>piscisaureus: but the identity stat.mode & 0777 == mode should hold evenon windows
13:25:12  <piscisaureus>DrPizza: but not: assert.equal(0777, fs.statSync(file).mode & 0777);
13:25:26  <indutny>ryah: yt?
13:26:01  <piscisaureus>indutny: you're a bit early, it's 6.30 am there
13:26:40  <indutny>piscisaureus: ah, SF
13:27:07  <piscisaureus>indutny: where are you based? asia somewhere?
13:27:21  <indutny>piscisaureus: yep, Russia, Omsk UTC+7
13:27:33  <indutny>Living in NY time zone, mostly
13:27:41  <piscisaureus>ah russia
13:27:52  <piscisaureus>yes, me and ben are sf time zone mostly
13:29:24  <indutny>I understand now
13:29:44  <indutny>don't know why, I thought Joyent is located in NY
13:30:25  * dmkbotquit (Remote host closed the connection)
13:30:35  * dmkbotjoined
13:36:48  <DrPizza>piscisaureus: why not, that's the bit I don't get
13:37:14  <DrPizza>piscisaureus: it's not doing 077, fs.stat.mode & 0777 for unix
13:37:26  <DrPizza>it's doing mode, fs.stat.mode & 0777
13:37:34  <DrPizza>and that should work on both platforms IMO
13:43:19  <piscisaureus>DrPizza: I think you're right
13:43:31  <piscisaureus>lets bug igorzi about that when he is here
13:44:07  <piscisaureus>DrPizza: although I think we better test for the exactly expected result
13:44:32  <DrPizza>I think i talready is for unix
13:53:18  <piscisaureus>I think there is a serious bug in tls.js
13:54:59  * dmkbot1joined
13:59:08  * dmkbotquit (Ping timeout: 276 seconds)
14:01:58  <piscisaureus>I wonder how I ever managed to work on node without msvs
14:02:15  <piscisaureus>ryah: https://github.com/joyent/node/blob/master/lib/tls.js#L375-396 <-- this needs to be updated for uv
14:10:03  <bnoordhuis>piscisaureus: does unix have struct sockaddr_storage? <- yes
14:10:33  <bnoordhuis>piscisaureus: also, is the family stored in struct sockaddr_storage.ss_family? <- yes
14:10:57  <piscisaureus>bnoordhuis: in that case node/master should still compile on unix :-)
14:11:12  <piscisaureus>(and have fewer bugs)
14:13:55  <bnoordhuis>compiles, let's see what `make test-all` says
14:14:21  <bnoordhuis>piscisaureus: let's do stdio and udp broadcast/multicast support next week
14:14:31  <piscisaureus>bnoordhuis: yes
14:14:52  <piscisaureus>bnoordhuis: I am now just killing bugs that are unexpected
14:14:57  <bnoordhuis>cool
14:15:16  <bnoordhuis>stdio api's design still needs some love, i think
14:15:21  <bnoordhuis>but we'll discuss it next week
14:15:22  <piscisaureus>yes, sure
14:19:18  <piscisaureus>bnoordhuis: do you understand anything about tls.js?
14:19:26  <bnoordhuis>piscisaureus: yes
14:19:31  <piscisaureus>bnoordhuis: ok
14:19:32  <piscisaureus>https://github.com/joyent/node/blob/master/test/simple/test-tls-peer-certificate.js#L41-54
14:19:41  <piscisaureus>bnoordhuis: I get ECONNABORTED on windows
14:19:57  <piscisaureus>bnoordhuis: apparently, the server end of the socket gets destroyed too soon
14:20:20  <piscisaureus>bnoordhuis: I can also verify that it's not doing a proper graceful close w/ tcp
14:20:26  <piscisaureus>which seems wrong to me
14:20:42  <bnoordhuis>let me quickly try it
14:21:02  <bnoordhuis>yes, wfm
14:21:39  <bnoordhuis>as it should, i think - the client request is done from within the 'listening' listener
14:21:41  <piscisaureus>bnoordhuis: it could be that the tls implementation relies on a particular ordering of events
14:22:14  <piscisaureus>bnoordhuis: it is not the server socket that gets destroyed - it is the server end, e.g. the accepted socket
14:22:40  <piscisaureus>bnoordhuis: apparently that cleartext.end('World') statement immediately kills the socket without even shutting it down
14:22:40  <bnoordhuis>oh, okay
14:23:18  <bnoordhuis>looking at tls.js now
14:23:31  <piscisaureus>bnoordhuis: good luck with that
14:24:00  <bnoordhuis>piscisaureus: is .writable stil true at that time?
14:24:20  <piscisaureus>bnoordhuis: the server end or the client end?
14:24:39  <bnoordhuis>let's start with the client end
14:25:23  <piscisaureus>bnoordhuis: no. neither are writable
14:26:36  <bnoordhuis>piscisaureus: https://gist.github.com/22370a60acfcf80f7bed <- can you apply that patch? so we're talking about the same thing
14:26:49  <piscisaureus>bnoordhuis: by the time the tls.connect callback is made socket.writable is already false
14:26:55  <piscisaureus>yeah let me apply that
14:28:27  <piscisaureus>bnoordhuis:
14:28:27  <piscisaureus>socket.writable true
14:28:27  <piscisaureus>cleartext.writable true
14:28:40  <bnoordhuis>piscisaureus: okay that's good
14:28:44  <bnoordhuis>i've updated the patch
14:29:03  <bnoordhuis>so it prints the status of .writable after the .end() call
14:29:10  <piscisaureus>bnoordhuis: can you just gist the file contents the next time?
14:29:15  <piscisaureus>copy paste > git apply :-)
14:29:18  <bnoordhuis>oh sure, let me do that
14:29:38  <piscisaureus>do it now
14:29:41  <bnoordhuis>piscisaureus: https://gist.github.com/4b5bac8d62624c53878b
14:30:02  <piscisaureus>socket.writable [1] true
14:30:02  <piscisaureus>socket.writable [2] false
14:30:02  <piscisaureus>cleartext.writable [1] true
14:30:02  <piscisaureus>cleartext.writable [2] false
14:30:08  <piscisaureus>bnoordhuis: ^
14:30:16  <bnoordhuis>okay, that's good
14:30:35  <bnoordhuis>so we probably need to move down the stack
14:30:59  <bnoordhuis>piscisaureus: does windows have something like strace?
14:31:06  <piscisaureus>ehh yeah
14:31:15  <piscisaureus>process monitor
14:31:18  <piscisaureus>let me do that
14:31:34  <bnoordhuis>i would like to know what the socket read and write syscalls return
14:31:48  <piscisaureus>bnoordhuis: this is iocp
14:31:51  <piscisaureus>spartaaa!
14:31:57  <bnoordhuis>oh damn
14:32:37  <bnoordhuis>piscisaureus: so where is that ECONNABORTED bubbling up from?
14:32:46  <piscisaureus>bnoordhuis: read()
14:33:06  <piscisaureus>more specifically, the overlapped 0-read returns it
14:33:31  <bnoordhuis>okay, so has the client closed its side of the connection before that?
14:34:57  <dmkbot1>joyent/node: teknopaul: path.normalize no longer works for URLs - https://github.com/joyent/node/issues/1676
14:35:22  <bnoordhuis>piscisaureus: https://gist.github.com/4b5bac8d62624c53878b <- does that work?
14:35:55  <piscisaureus>bnoordhuis: strace -> https://docs.google.com/spreadsheet/ccc?key=0AncAtEVJvlbUdFlyd1BkcjdMNFpmTzllLVV6dk55Q0E&hl=nl
14:37:00  <piscisaureus>bnoordhuis: I gotta explain how to analyze that :-)
14:37:06  <piscisaureus>but let me try the patch first
14:37:36  <piscisaureus>bnoordhuis: re does that work -> no
14:37:45  <bnoordhuis>okay
14:41:05  <piscisaureus>bnoordhuis: that spreadsheet has now only tcp events
14:41:23  <piscisaureus>bnoordhuis: ignore aeu.b, it just means localhost
14:41:41  <bnoordhuis>so... success only?
14:41:54  <piscisaureus>hmm. yeah that's weird
14:42:03  <piscisaureus>let me see why
14:42:09  <piscisaureus>maybe I filtered one too many
14:43:01  <bnoordhuis>no, i think you got them all
14:43:24  <bnoordhuis>downloaded the original spreadsheet as a csv and the tcp entries are all marked with success
14:44:11  <bnoordhuis>maybe a libuv bug, put a breakpoint on your tcp error handling code
14:44:25  <piscisaureus>bnoordhuis: it is rather a process explorer bug
14:44:39  <bnoordhuis>why?
14:46:04  <piscisaureus>hmm
14:46:27  <piscisaureus>bnoordhuis: because i see uv_process_tcp_read_req down the stack
14:46:36  <piscisaureus>bnoordhuis: but it got me thinking ,,,
14:46:57  <piscisaureus>what if the uv-win is dropping the accept socket
14:47:08  <bnoordhuis>dropping as in ...?
14:47:12  <piscisaureus>closing it
14:47:16  <piscisaureus>failing the accept call
14:47:31  <piscisaureus>bnoordhuis: otherwise we should not see WSAECONNABORTED
14:47:37  <piscisaureus>but rather ECONNRESET
14:47:55  <bnoordhuis>okay, makes sense
14:48:02  <bnoordhuis>but do you actually see that happening?
14:48:11  <bnoordhuis>easy to test, i would think
14:48:12  <piscisaureus>let me trace
14:48:18  <piscisaureus>yes
14:48:19  <piscisaureus>well...
14:48:26  <piscisaureus>it's a little more difficult on windows that linux
14:48:30  <piscisaureus>but still easy to trace
14:48:34  <bnoordhuis>printf style debugging ftw!
14:48:42  <piscisaureus>oh, no that's not it
14:48:49  <piscisaureus>but the accept happens in the backround you see
14:49:08  <piscisaureus>it can fail at the submit point or the return point
14:50:58  <piscisaureus>bnoordhuis: aha!
14:51:23  <bnoordhuis>eureka?
14:51:34  <piscisaureus>bnoordhuis: that's it. it's completely unrelated to the test or so it seems
14:51:48  <piscisaureus>after the initial connection I see another connection coming in ... a failed one
14:51:58  <piscisaureus>probably it's just the server that is closing
14:52:36  <piscisaureus>but still I wonder why it is starting a read on that socket (or the other end)
14:53:25  <bnoordhuis>so you're seeing a ghost accept call?
14:53:39  <piscisaureus>bnoordhuis: well... maybe
14:54:13  <bnoordhuis>oh, it's a heisenberg accept call
14:54:14  <piscisaureus>bnoordhuis: but it can also be that it is just an overlapped accept call that returns without having accepted, because the listening socket is closing
14:54:32  <piscisaureus>bnoordhuis: but the weird thing is, that socket has another end
14:54:39  <piscisaureus>an end that is seeing ECONNABORTED
14:55:26  <piscisaureus>it still puzzles me
14:55:37  <piscisaureus>bnoordhuis: but thanks for your time anyway.
14:55:51  <piscisaureus>sorry about all the bullshit theories i have posted in this channel this afternoon
14:55:59  <bnoordhuis>piscisaureus: what do you see when you run `NODE_DEBUG=net ./node_g test/simple/test-tls-peer-certificate.js`?
14:56:00  <bnoordhuis>heh
14:56:56  <piscisaureus>bnoordhuis: https://gist.github.com/1206442
14:57:53  <bnoordhuis>piscisaureus: posted a comment
14:58:03  <bnoordhuis>odd, i'm seeing this:
14:58:04  <bnoordhuis>NET: afterConnect
14:58:04  <bnoordhuis>NET: Drain the connect queue
14:58:04  <bnoordhuis>NET: onconnection
14:58:20  <bnoordhuis>while you are seeing this:
14:58:20  <bnoordhuis>NET: onconnection
14:58:20  <bnoordhuis>NET: afterConnect
14:58:20  <bnoordhuis>NET: Drain the connect queue
14:59:27  <piscisaureus>bnoordhuis: on linux the connection and connected events are reversed
14:59:56  <bnoordhuis>piscisaureus: no you
15:00:08  <bnoordhuis>sorry, i meant: no u
15:01:04  <bnoordhuis>but isn't that a bug?
15:01:16  <piscisaureus>bnoordhuis: not necessarily
15:01:23  <piscisaureus>maybe it indicates a bug
15:01:40  <bnoordhuis>different platforms, different behaviour - i don't like that
15:01:47  <piscisaureus>bnoordhuis: but there is no guarantee in which order libuv reports connections and connected
15:02:32  <piscisaureus>bnoordhuis: remember, this is a server. normally you don't even connect to yourself
15:02:44  <piscisaureus>your program should definitely not rely on any particular ordering
15:02:52  <bnoordhuis>i understand and appreciate that
15:02:56  <bnoordhuis>still makes me uneasy
15:03:00  <bnoordhuis>but okay, let's move on
15:03:14  <piscisaureus>bnoordhuis: have a valiumpje
15:04:52  <bnoordhuis>well, i'm not sure what's causing it to fail for you
15:05:04  <bnoordhuis>i don't see obvious bugs in either the test or tls.js
15:09:10  * piscisaureuspart
15:12:04  * piscisaureusjoined
15:16:37  <piscisaureus>bnoordhuis: got it. will explain over 5 minuten
15:17:19  <bnoordhuis>ack
15:17:27  <piscisaureus>maybe 10
15:17:30  <piscisaureus>:-)
15:23:09  <piscisaureus>bnoordhuis: hmm. it is a problem with tls after all
15:23:53  <bnoordhuis>piscisaureus: do tell
15:24:14  <piscisaureus>bnoordhuis: server.close() was just blurring my view.
15:24:19  <piscisaureus>but look here: https://gist.github.com/1206510
15:24:48  <bnoordhuis>4 extra sockets?
15:24:59  <piscisaureus>bnoordhuis: no, that's not it
15:25:11  <piscisaureus>bnoordhuis: that cleartext.end is destroying the underlying socket too soon
15:25:51  <piscisaureus>bnoordhuis: it shouln', it should attempt graceful shutdown
15:25:51  <bnoordhuis>piscisaureus: how so?
15:26:32  <piscisaureus>bnoordhuis: the server-end socket is closed before the client even knows it's connected
15:26:41  <piscisaureus>so the client thinks something went horribly wrong
15:27:23  <piscisaureus>bnoordhuis: don't be distracted by that read fail: 388 btw - that's expected
15:28:28  <bnoordhuis>piscisaureus: okay - but where/how in tls.js is the server socket destructed too soon?
15:31:01  <CIA-52>node: Ben Noordhuis master * rfa334ef / wscript : build: install uv-private/*.h, fixes native add-on builds - http://git.io/JSrNFw
15:32:44  <piscisaureus>bnoordhuis: at Socket.destroy (net_uv.js:264:18)
15:32:44  <piscisaureus>at EncryptedStream.onclose (stream.js:92:10)
15:32:44  <piscisaureus>at EncryptedStream.emit (events.js:88:20)
15:32:44  <piscisaureus>at Array.<anonymous> (tls.js:682:22)
15:32:44  <piscisaureus>at EventEmitter._tickCallback (node.js:195:26)
15:34:22  <bnoordhuis>ah
15:35:04  <piscisaureus>bnoordhuis: if I swap dest.destroy for destroy.end the test passes
15:35:04  <piscisaureus>destroySoon() doesn't help
15:35:22  <bnoordhuis>what happens if you change line 243 in tls.js from this:
15:35:23  <bnoordhuis>this.pair.destroy();
15:35:33  <bnoordhuis>to: process.nextTick(function() { this.pair.destroy(); });
15:36:15  <piscisaureus>bnoorhuis: let's make it
15:36:15  <piscisaureus>var self = this;
15:36:15  <piscisaureus> process.nextTick(function () { self.pair.destroy(); });
15:36:15  <piscisaureus>shall we :-)
15:36:34  <piscisaureus>bnoordhuis: doesn't help
15:37:11  <piscisaureus>bnoordhuis: probably that is because the pair.destroy() still gets inserted before the connect callback is called
15:37:30  <piscisaureus>because nextTick() short-circuits and takes precedence over io events
15:37:37  <bnoordhuis>right
15:38:24  <piscisaureus>brb
15:59:55  <ryah>piscisaureus: how's it going?
16:01:20  <piscisaureus>ryah: looking good
16:01:33  <ryah>indutny: yo
16:02:34  <piscisaureus>bnoordhuis: what about making that destroy a .end? or maybe make it a end on windows only and only if the socket hasn't received anything from the other end
16:02:37  <ryah>piscisaureus: felixge is here - im going to take him to the office - and i'll be ready to continue in approximately 1 hour
16:02:59  <piscisaureus>ryah: ok.
16:03:20  <bnoordhuis>piscisaureus: what .end method are we talking about here?
16:03:35  * dmkbot1quit (Remote host closed the connection)
16:03:49  <bnoordhuis>ryah: say hi to felix from me
16:03:52  * dmkbotjoined
16:03:59  <piscisaureus>yes from me too
16:04:49  <piscisaureus>bnoordhuis: https://github.com/joyent/node/blob/master/lib/stream.js#L92
16:04:56  <piscisaureus>bnoordhuis: if I make that an .end it work
16:05:19  <piscisaureus>bnoordhuis: but maybe the tls stream is just wrong and should not emit 'close' but something else
16:06:07  <ryah>piscisaureus: what about tls.js needs to be updated?
16:06:12  <ryah>the fact that it prints .fd ?
16:06:17  <piscisaureus>ryah: nonono
16:06:24  <piscisaureus>ryah: sorry - my comment there was wrong
16:06:39  <piscisaureus>ryah: but I am seeing test-tls-peer-certificate fail
16:07:13  <piscisaureus>ryah: because on windows the accepted socket gets destroyed too soon. tls does not attempt to shut down gracefully, it just kills the socket
16:07:20  * felixgejoined
16:07:27  <piscisaureus>(and I think that could be wrong)
16:10:12  <bnoordhuis>piscisaureus: i don't think we should change stream.js
16:10:32  <piscisaureus>bnoordhuis: no, that's too hot to handle
16:10:33  <bnoordhuis>but presumably tls.js should end the stream, not close it
16:10:40  <piscisaureus>bnoordhuis: yes
16:11:25  <bnoordhuis>piscisaureus: let me check if that works correctly here
16:12:01  <piscisaureus>I think this relates to 2 more failures on windows
16:12:14  <piscisaureus>at least test-regress-GH-1531
16:14:33  <bnoordhuis>piscisaureus: https://gist.github.com/cf200af99b4ae26eb5a1 <- passes test-tls-peer-certificate.js but hangs other tls tests :/
16:15:14  <piscisaureus>bnoordhuis: aren't those other tests just observing the close event
16:15:33  <piscisaureus>bnoordhuis: maybe we should carry this to the scrum call tonight
16:16:22  <bnoordhuis>piscisaureus: yes, let me check that
16:16:22  <piscisaureus>although - I'd like to have a proposed fix then :-)
16:16:29  <bnoordhuis>the majority seems to pass
16:19:02  <piscisaureus>bnoordhuis: the risk is that we subtly break node programs that rely on close
16:19:43  <bnoordhuis>i wouldn't use the word 'subtly' here :)
16:20:46  <bnoordhuis>piscisaureus: https://gist.github.com/cf200af99b4ae26eb5a1 <- that makes the tests pass
16:21:23  <piscisaureus>bnoordhuis: ok, thanks
16:21:27  <piscisaureus>I am going to try that on windows
16:21:34  <piscisaureus>let's discuss this patch with ryah asap
16:22:01  <piscisaureus>bnoordhuis: maybe we should make sure that the cleartext/encrypted streams emit close too
16:22:05  <piscisaureus>just like other streams do
16:22:21  <bnoordhuis>yes maybe
16:22:32  <bnoordhuis>ot1h, backwards compatibility is a good thing
16:22:40  <bnoordhuis>otoh, you don't want to carry too much cruft along
16:23:05  <piscisaureus>bnoordhuis: I'm not doing it for backward compatibility
16:23:14  <piscisaureus>bnoordhuis: it should just adhere to the stream specifications
16:23:43  <bnoordhuis>hmm, i suppose that's a fair point
16:24:04  <bnoordhuis>do streams guarantee that a close event's emitted?
16:24:31  <bnoordhuis>close -> Emitted when the underlying file descriptor has been closed.
16:24:34  <bnoordhuis>what file descriptor?
16:24:55  <piscisaureus>bnoordhuis: the socket fd?
16:25:09  <piscisaureus>bnoordhuis: let's discuss with ryah
16:25:15  <piscisaureus>the boss and the streams guy
16:25:26  <piscisaureus>so let's discuss with ryah and felix
16:25:28  <bnoordhuis>the streams guy, that's felixge
16:25:31  <bnoordhuis>right :)
16:26:15  <bnoordhuis>reading streams.markdown, i think emitting end followed by close should cover all bases
16:26:56  <piscisaureus>bnoordhuis: bbl. dinnner
16:27:10  <bnoordhuis>right, 18:30 already
16:30:02  <ryah>bbiab
16:30:34  <indutny>ryah: yo!
16:30:39  <bnoordhuis>piscisaureus: when you're back: https://gist.github.com/cf200af99b4ae26eb5a1 <- passes tls and https tests
16:30:46  <indutny>ryah: brb, rebooting to linux
16:32:41  <indutny>back
16:33:07  <indutny>time to merge branchees! :)
16:33:24  <bnoordhuis>indutny: i think ryah just went afk
16:33:39  <indutny>bnoordhuis: hehe :)
16:33:54  <felixge>bnoordhuis: he is on his keyboard
16:34:05  <felixge>bnoordhuis: but I guess he is away from this window
16:34:06  <felixge>:)
16:34:13  <indutny>felixge: :)
16:34:30  <bnoordhuis>felixge: what brings you to SF?
16:34:39  <felixge>bnoordhuis: node
16:35:01  <bnoordhuis>felixge: node no longer runs in germany?
16:35:03  <felixge>bnoordhuis: well that, and that microsoft is sending me to their BUILD conference next week
16:35:08  <bnoordhuis>ah cool
16:35:09  <felixge>so I had a free ride to piggy back on
16:36:11  <DrPizza>felixge: orly
16:36:23  <DrPizza>will there be node presentations at BUILD?
16:36:24  <indutny>bnoordhuis: "https://gist.github.com/cf200af99b4ae26eb5a1" <- so many problems with that cleartext/encrypted thing
16:36:55  <felixge>DrPizza: no, I'm just attending
16:36:56  <felixge>it's weird
16:37:12  <felixge>some german MS Evangelist contacted me out of the blue with the offer
16:37:14  <bnoordhuis>indutny: yes - usually hard to debug too
16:37:27  <DrPizza>felixge: weird
16:37:51  <felixge>DrPizza: well, I might have to sell my soul
16:37:58  <felixge>so I don't know if it's a good deal yet
16:37:59  <felixge>;)
16:38:03  <DrPizza>a small price to pay
16:39:39  <felixge>DrPizza: I have already sold my soul, so yes
16:39:40  <felixge>:)
16:39:41  * felixgequit (Quit: felixge)
16:45:58  * isaacsjoined
16:52:23  <indutny>ryah: please ping me when you'll get back here
17:21:41  * isaacsquit (Quit: isaacs)
17:24:47  * graydonjoined
17:28:05  <ryah>indutny: ping
17:28:21  <indutny>ryah: hi!
17:28:25  <indutny>good morning/day
17:28:33  <indutny>can you please review this https://github.com/joyent/node/pull/1673 ?
17:28:49  <indutny>and then this https://github.com/joyent/node/pull/1667 :D
17:29:05  <ryah>indutny: going to wait until after the release - we're still trying to ship it
17:29:16  <ryah>but i will merge this weekend
17:29:17  <indutny>ok
17:29:20  <indutny>any problems?
17:29:23  <indutny>with release
17:29:32  <indutny>can I be useful?
17:29:32  <ryah>indutny: there were some problems yesterday, yes
17:35:51  * brsonjoined
17:59:57  <piscisaureus>bnoordhuis: yt
17:59:58  <piscisaureus>?
18:00:12  <bnoordhuis>piscisaureus: yes
18:00:13  <bnoordhuis>call time?
18:00:20  <piscisaureus>I would think so
18:00:34  <piscisaureus>bnoordhuis: maybe wait 5 minutes, then I can test your patch
18:02:26  <piscisaureus>bnoordhuis: which patch is it again? https://gist.github.com/cf200af99b4ae26eb5a1 <-- this?
18:02:38  <bnoordhuis>piscisaureus: yes
18:02:46  <piscisaureus>bnoordhuis: seems incomplete
18:02:47  <ryah>piscisaureus: https://gist.github.com/1206896
18:03:11  <piscisaureus>bnoordhuis: bit I'll try anyway
18:03:31  <ryah>is it call time?
18:03:32  <bnoordhuis>incomplete? well, i never
18:03:50  <bnoordhuis>piscisaureus wants to wait a few more minutes
18:06:18  <piscisaureus>bnoordhuis: well, the patch does it
18:06:22  <piscisaureus>ok, call time
18:07:03  <bnoordhuis>ready and waiting
18:07:07  <piscisaureus>ryah: let's try it once
18:07:08  <bnoordhuis>like your girlfriend
18:07:09  <ryah>piscisaureus, bnoordhuis, igorzi: i just sent an email with a confernce line
18:07:27  <ryah>because we are 3 people here
18:07:58  <piscisaureus>okay
18:08:08  <igorzi>are we doing the call now? or at noon?
18:08:27  <bnoordhuis>will have to check if i can actually call internationally with my landline...
18:08:42  <piscisaureus>bnoordhuis: it's too expensive; use skype
18:09:22  <ryah>igorzi: sorry - if you can now?
18:09:40  <ryah>if not we can wait
18:09:42  <igorzi>yeah, no prob
18:09:49  <bnoordhuis>piscisaureus: you need skype credit for that, don't you?
18:09:57  <piscisaureus>bnoordhuis: yes, I have that
18:10:02  <bnoordhuis>piscisaureus: i don't
18:10:05  <piscisaureus>maybe we should keep it short
18:10:17  <ryah>we can do skype too if it's too hard
18:10:22  <bnoordhuis>yes, please
18:10:24  <ryah>ok
18:12:48  <piscisaureus>https://raw.github.com/gist/cf200af99b4ae26eb5a1/a870cf82b7804ece948ac5eadb7b38e9df2a2785/tls.patch
18:19:49  <bnoordhuis>igorzi: your patch for test/simple/test-fs-chmod.js breaks it on unix
18:21:07  <bnoordhuis>AssertionError: 511 == 329
18:21:08  <bnoordhuis> at Object.oncomplete (/home/bnoordhuis/src/nodejs/node/test/simple/test-fs-chmod.js:52:14)
18:23:30  <piscisaureus>igorzi: bnoordhuis: can you fix the chmod test now? then I can create rc2 after that
18:23:36  <igorzi>strange, isn't it doing on unix exactly the same as it before?
18:23:45  <bnoordhuis>igorzi: evidently not :)
18:23:53  <bnoordhuis>let me strace it
18:25:57  <bnoordhuis>piscisaureus: i've been informed that it's dinner time for me
18:26:07  <bnoordhuis>so... back in an hour
18:26:26  <igorzi>ok, i'll figure it out (i can repeat it on unix)
18:26:26  * ericktjoined
18:28:51  <erickt>Good morning #libuv. I noticed that it seems a bunch of the public uv_req_t functions aren't checking if the provided req isn't null (like uv_fs_open), but uv_getaddrinfo is checking. Should all those functions be changed to test for an invalid value?
18:29:48  <ryah>erickt: i suppose
18:38:49  <erickt>also, digging around in the uv_getaddrinfo code, we could theoretically just not use memset to clear out the uv_getaddrinfo_t, which would once again allow you to set the uv_getaddrinfo_t->data without needing to pass in a "void* data"
18:39:39  <piscisaureus>ryah: added a tab to the sheet
18:40:18  * brsonquit (Ping timeout: 260 seconds)
18:41:02  <piscisaureus>ryah: it would be nice if we could have at least 4 build bots. osx linux windows sunos
18:41:11  <piscisaureus>that worked well
18:42:17  <piscisaureus>btw, test-timers is a small concern, test-keep-alive should not crash :-/
18:47:44  <igorzi>piscisaureus: https://github.com/igorzi/node/commit/767b1ae86a92ea2596de6e0eefccbbcea0905bb6
18:55:43  <ryah>piscisaureus: i can't see the new column
19:04:49  <piscisaureus>ryah: I added a new tab. I guess we can copy-paste?
19:05:36  <ryah>piscisaureus: https://gist.github.com/1207050 <-- sunos
19:06:39  <ryah>piscisaureus: ah, new tab, okay
19:07:38  <piscisaureus>ryah: let me improve the script later
19:07:42  <ryah>okay - yeah
19:07:44  <piscisaureus>first cut the rc
19:09:06  <igorzi>DrPizza: on unix, if you start out with a file where stat.mode = 0100666, then do chmod(0400), (stat.mode & 0777) will be 0400.
19:09:23  <DrPizza>right
19:09:33  <DrPizza>stat.mode & 0777 should match the mode passed to chmod
19:09:37  <ryah>groan
19:09:41  <ryah>there are some problems on unix
19:09:44  <igorzi>DrPizza: but not on windows
19:10:18  <DrPizza>igorzi: why not?
19:10:20  <igorzi>on windows (stat.mode & 0777) will be 0444
19:10:25  <CIA-52>node: Igor Zinkovsky master * r79ce48d / test/simple/test-fs-chmod.js : fix for test-fs-chmod - http://git.io/X7mykg
19:10:45  <DrPizza>igorzi: I think the group and other bits should be masked off by libuv
19:10:55  <DrPizza>since they don't exist on windows
19:12:50  <igorzi>hmm
19:13:19  <igorzi>piscisaureus: what do you think?
19:14:26  <piscisaureus>shrug, dunno, this seems fine
19:14:30  <piscisaureus>after the release, please
19:14:42  <piscisaureus>let's get the tree reopened first
19:15:32  <ryah>meh, test/pummel/test-keep-alive.js is segfaulting on OSX and i dont really know why
19:15:39  <ryah>it seems to be getting SIGPIPE ...
19:15:42  <ryah>even though we ignore it
19:16:20  <ryah>bnoordhuis: does this sound familiar? we're not unignoring it somehow?
19:16:22  <igorzi>piscisaureus: DrPizza: ok, let's keep it as is for this release, and mask off the bits that don't exist on windows for next release
19:16:31  <DrPizza>ok
19:16:34  <DrPizza>sounds like a plan
19:22:01  <piscisaureus>ryah: cut rc2 anyway?
19:22:16  <ryah>piscisaureus: ok
19:22:23  <piscisaureus>ryah - or?
19:22:24  <piscisaureus>you tell me
19:23:07  <ryah>piscisaureus: yes, please
19:25:08  <piscisaureus>2m50s remaining
19:26:08  <piscisaureus>1m50s remaining
19:32:51  <piscisaureus>ryah: http://nodejs.org/dist/v0.5.5/node-v0.5.6-rc2.tar.gz
19:35:22  <ryah>piscisaureus: okay - im going to start the tests
19:35:31  <ryah>fuck i kind of think we should fix this sigpipe issue
19:35:42  <piscisaureus>ryah: You can do that if you want
19:35:49  <piscisaureus>ryah: I am going to start xp testing
19:36:24  <ryah>piscisaureus: your tar file is messed up
19:36:31  <ryah>piscisaureus: i can't untar it with gnu tar
19:36:31  <piscisaureus>oh?
19:36:46  <ryah>% tar -zvxf node-v0.5.6-rc2.tar.gz
19:36:50  <ryah>
19:36:53  <ryah>gzip: stdin: not in gzip format
19:36:57  <ryah>tar: Child returned status 1
19:37:00  <ryah>tar: Error exit delayed from previous errors
19:37:06  <piscisaureus>hmm
19:37:17  <piscisaureus>works here
19:37:21  <piscisaureus>also with rar
19:37:46  <ryah>piscisaureus: do the 'make dist' on linux please
19:40:06  <piscisaureus>ryah: http://nodejs.org/dist/v0.5.6/node-v0.5.6-rc2.tar.gz
19:40:10  <piscisaureus>ryah: the url was wrong
19:47:05  <piscisaureus>this windows build is as good as it gets - now trying mingw on xp
19:53:01  <piscisaureus>sigh. ENOENT still != UNKNOWN
20:01:19  <piscisaureus>[03:34|% 100|+ 244|- 36]: Done
20:01:22  <piscisaureus>^-- xp. not bad
20:03:38  <erickt>ryah: got a moment to talk uv_getaddrinfo?
20:13:08  <piscisaureus>win 7: [02:59|% 100|+ 245|- 35]: Done
20:33:17  <piscisaureus>[03:11|% 100|+ 270|- 10]: Done
20:33:17  <piscisaureus>^-- linux
20:33:18  <piscisaureus>test-child-process-ipc: crashed
20:33:18  <piscisaureus>test-fs-error-messages: src/unix/fs.c:88: uv_fs_req_cleanup: Assertion `req->ptr' failed.
20:33:23  <piscisaureus>otherwise looking good
20:33:26  <piscisaureus>ryah: ^
20:33:47  <bnoordhuis>yes, i'm seeing that too
20:36:16  <piscisaureus>bnoordhuis: both?
20:36:35  <ryah>bnoordhuis: please run ./node_g test/pummel/test-keep-alive.js
20:36:52  <bnoordhuis>piscisaureus: the fs.c assertion, not that test-child-process-ipc crashes
20:37:06  <piscisaureus>ryah: bnoordhuis: test-child-process-ipc crashes with EPIPE for me
20:37:18  <piscisaureus>ehm
20:37:21  <piscisaureus>SIGPIPE I mean
20:37:36  <bnoordhuis>ryah: test-keep-alive crashes with SIGSEGV for me
20:38:16  <ryah>http://support.microsoft.com/kb/156932 <-- async file i/o in windows is fucked
20:38:32  <bnoordhuis>wait, not SIGSEGV but SIGPIPE
20:38:36  <ryah>yeah
20:38:40  <ryah>why are we crashing with SIGPIPE?
20:39:22  <piscisaureus>ryah: I already knew... But if it would happen *only* in the situations outlined in that documument, it would be fine, we could work around it
20:39:37  <piscisaureus>ryah: sadly, not the case
20:40:39  <ryah>my friend at chrome is telling me that because of this all async i/o in chrome is busted
20:41:15  <piscisaureus>they should have tried before implementing it
20:41:28  <piscisaureus>but again, if it were only that, it would be acceptable
20:41:47  <piscisaureus>use FILE_FLAG_NO_BUFFERING, then it works fine
20:42:03  <piscisaureus>(btw, we could use that for read streaming in libuv right?)
20:42:36  <ryah>bnoordhuis: https://github.com/joyent/node/blob/79ce48d/src/node.cc#L2434
20:42:36  <piscisaureus>and we could linux async io on linux
20:43:29  <bnoordhuis>ryah: yes...
20:43:42  <ryah>i think this is a blocker
20:44:08  <bnoordhuis>you know, there's something fishy altogether
20:44:13  <bnoordhuis>it also crashes with this: *** glibc detected *** ./node_g: free(): invalid pointer: 0x00003c0283f9f691 ***
20:44:43  <igorzi>with FILE_FLAG_NO_BUFFERING file i/o should be async, but buffers need to be properly aligned though - http://msdn.microsoft.com/en-us/library/cc644950(v=vs.85).aspx
20:45:39  <piscisaureus>igorzi: I know. And you need to read 512 bytes at a time, aligned to disk sectors
20:47:58  <bnoordhuis>i have a hunch that it's got something to do with https://github.com/joyent/libuv/commit/431195c - the invalid free is coming from uv__stream_destroy
20:50:36  <ryah>can we revert that?
20:50:45  <bnoordhuis>yes, and if do the test passes
20:50:50  <bnoordhuis>*if i
20:51:41  <bnoordhuis>but i don't think that commit is the real culprit, just exposing a bug somewhere else
20:53:46  <piscisaureus>ryah: it seems that EPIPE is successfully ignored here
20:54:15  <piscisaureus>I can just `cont` after that, then it'll crash with:
20:54:16  <piscisaureus>child end
20:54:16  <piscisaureus>node.js:203
20:54:16  <piscisaureus> throw e; // process.nextTick error, or 'error' event on first tick ^
20:54:16  <piscisaureus>Error: write EPIPE
20:54:16  <piscisaureus> at errnoException (net_uv.js:557:11)
20:54:16  <piscisaureus> at Socket.write (net_uv.js:385:18)
20:54:17  <piscisaureus> at Socket.<anonymous> (/home/bert/node/test/simple/test-child-process-ipc.js:47:17)
20:54:17  <piscisaureus> at Socket.emit (events.js:67:17)
20:54:18  <piscisaureus> at Pipe.onread (net_uv.js:293:31)
20:54:18  <piscisaureus>[Thread 0xb7fc5b70 (LWP 5170) exited]
20:54:19  <piscisaureus>Program exited with code 01.
20:55:06  <ryah>reverting bnoordhuis's commit does not make SIGPIPE go away
20:55:38  <piscisaureus>I think this is the linux variation of the same bug that makes test-cli-eval fail on windows
20:56:22  <piscisaureus>which is, closing the child end of stdout/stderr too soon
20:56:49  <ryah>no the problem is we're getting a signal that we shouldn't
20:56:59  <ryah>i dont really care if this test fails
20:58:27  <bnoordhuis>one thing that test does, is write to the handle after it's closed
20:58:56  <piscisaureus>so?
20:58:59  <piscisaureus>it returns EPIPE
20:59:02  <piscisaureus>is that bad?
20:59:10  <bnoordhuis>https://gist.github.com/8ecfddd74773a016c893 <-patch that shows that
21:00:12  <ryah>returning EPIPE isn't bad - but getting the signal is
21:00:53  <ryah>in unix by default it returns EPIPE and sends you SIGPIPE
21:01:16  <ryah>(this is so "cat file | head -1" works)
21:01:49  <ryah>the cat process gets SIGPIPE and dies after the pipe is closed
21:02:55  <ryah>if i dtruss it, i definitely see the sigaction being set
21:03:00  <ryah>bnoordhuis: we should valgrind
21:03:09  <bnoordhuis>ryah: working on it :)
21:03:19  <bnoordhuis>but you know valgrind, no speed daemon
21:05:37  <bnoordhuis>==22245== Invalid read of size 8
21:05:37  <bnoordhuis>==22245== at 0xA227C6: uv__clear_queue (stream.c:87)
21:05:37  <bnoordhuis>==22245== by 0xA2288D: uv__stream_destroy (stream.c:102)
21:05:37  <bnoordhuis>==22245== by 0xA1B58E: uv__finish_close (core.c:240)
21:05:37  <bnoordhuis>==22245== by 0xA1B733: uv__next (core.c:278)
21:05:38  <bnoordhuis>==22245== by 0xA28F31: ev_invoke_pending (ev.c:2143)
21:05:40  <bnoordhuis>==22245== by 0xA29CF5: ev_run (ev.c:2519)
21:05:42  <bnoordhuis>==22245== by 0xA1B2F4: uv_run (core.c:186)
21:05:44  <bnoordhuis>==22245== by 0x63AE30: node::Start(int, char**) (node.cc:2533)
21:05:46  <bnoordhuis>==22245== by 0x632E6F: main (node_main.cc:25)
21:05:48  <bnoordhuis>==22245== Address 0x7d80460 is 48 bytes inside a block of size 152 free'd
21:05:50  <bnoordhuis>==22245== at 0x4C26DCF: operator delete(void*) (vg_replace_malloc.c:387)
21:05:54  <bnoordhuis>==22245== by 0x65CBF1: node::StreamWrap::Write(v8::Arguments const&) (stream_wrap.cc:250
21:07:59  * mralephjoined
21:10:25  <piscisaureus>why are you guys using sigfillset btw?
21:10:29  <piscisaureus>(and not sigemptyset?)
21:12:30  <bnoordhuis>piscisaureus: to block all other signals when the signal handler runs
21:15:14  <piscisaureus>look. here's what I am seeing. When I run it without gdb (either node or node_g) it just dies with EPIPE
21:15:27  <piscisaureus>only when I run with gdb I actually see SIGPIPE
21:15:50  <piscisaureus>but couln't it be that SIG_IGN refers to some dummy procedure
21:16:05  <piscisaureus>but gdb intercepts the SIGPIPE anyway, before it reaches this dummy function
21:16:14  <piscisaureus>why not try to block the signal completely?
21:16:20  <piscisaureus>(w/ sigprocmask)
21:16:46  <bnoordhuis>sigprocmask is not thread-safe
21:16:56  <bnoordhuis>or rather, thread-aware
21:17:16  <bnoordhuis>you need pthread_sigprocmask for that
21:17:40  <bnoordhuis>SIG_IGN is not a dummy signal handler btw, it's handled inside the kernel
21:17:52  <bnoordhuis>that is, the signal never reaches the process
21:20:02  <piscisaureus>bnoordhuis: anyway, it doesn't seem to work
21:20:03  <piscisaureus>sigset_t newset;
21:20:03  <piscisaureus>sigemptyset(&newset);
21:20:04  <piscisaureus>sigaddset(&newset,SIGPIPE);
21:20:04  <piscisaureus>sigprocmask (SIG_BLOCK, &newset, NULL);
21:20:10  <piscisaureus>^-- this however, works fine for me
21:20:13  <piscisaureus>no more SIGPIPE
21:24:45  <piscisaureus>bnoordhuis: also interesting. It doesn't seem that the process is actually killed by SIGPIPE
21:24:52  <piscisaureus>it is killed by SIGSEGV
21:25:39  <bnoordhuis>piscisaureus: https://github.com/joyent/libuv/commit/431195c <- if i back out that patch, the test passes
21:25:44  <bnoordhuis>without memory corruption either
21:26:04  <ryah>bnoordhuis: not me
21:26:06  <ryah>let me try again
21:26:06  <piscisaureus>bnoordhuis: what's wrong with that patch
21:26:44  <bnoordhuis>piscisaureus: afaict nothing, i suspect it exposes a bug in node
21:26:59  <bnoordhuis>if, for example, i run tcp_writealot through valgrind, all goes well
21:27:33  <bnoordhuis>ryah: you still get the SIGPIPE but node won't crash anymore
21:27:38  <piscisaureus>bnoordhuis: tcp_writealot writes small chunks
21:27:47  <piscisaureus>bnoordhuis: you should try benchmark-pump
21:27:52  <piscisaureus>erm
21:28:02  <piscisaureus>tcp_writealot writes big chunks, is what i meant :-/
21:28:37  <piscisaureus>bnoordhuis: also, the req could be freed by the callback
21:28:50  <piscisaureus>so you can't reference req->buf[sml] after making the callback
21:28:55  <piscisaureus>bnoordhuis: so that patch is definitely wrong
21:29:59  <piscisaureus>bnoordhuis: try moving that free() part before the callback
21:30:42  <bnoordhuis>piscisaureus: good point, it shouldn't free at all for the completed queue
21:30:59  <piscisaureus>bnoordhuis: it should free
21:31:11  <piscisaureus>bnoordhuis: bufs may be malloced() inside libuv
21:31:30  <ryah>okay nevermind
21:31:31  <piscisaureus>bnoordhuis: that free code looks right to me, but it's at the wrong place
21:31:35  <ryah>a clean build also fixed it
21:31:40  <ryah>reverting that patch
21:31:45  <piscisaureus>ryah: noooo
21:31:51  <piscisaureus>ryah: read up!
21:32:17  <ryah>fine
21:33:18  <bnoordhuis>piscisaureus: btw, https://github.com/joyent/libuv/blob/master/src/unix/stream.c#L341
21:33:49  <ryah>im rebuilding with the free moved up
21:34:02  <piscisaureus>bnoordhuis: that looks bug-free to me
21:34:42  <bnoordhuis>piscisaureus: yes, but that's why i shouldn't free for the write_completed_queue
21:35:19  <piscisaureus>bnoordhuis: ok - you know uv-unix better than me. I just though this clear__queue was to clean out cancelled writes
21:35:41  <bnoordhuis>piscisaureus: yes, but it runs callbacks for both pending and completed writes
21:36:09  <piscisaureus>my gut feeling there must be a leak in here :-)
21:36:22  <piscisaureus>ok now I am the annoying guy - sorry
21:36:37  <ryah>okay - so moving the free up also causes segfaul
21:36:54  <ryah>SIGPIPE
21:37:05  <ryah>revert that patch?
21:37:12  <piscisaureus>ryah: does your program actually die with sigpipe?
21:37:18  <ryah>yes
21:37:22  <piscisaureus>I mean the sigpipe can't be caused by that patch right?
21:37:37  <ryah>i assume there is some memory corruption
21:37:39  <bnoordhuis>uv_err_new (loop=0x1baddead0baddeaf, sys_error=16) <- gdb :)
21:37:53  <bnoordhuis>okay, let's back out the patch
21:37:58  <bnoordhuis>i'll do it
21:38:12  <piscisaureus>hmm
21:38:22  <piscisaureus>so you guys are now swapping a crash for a leak
21:38:27  <piscisaureus>:-/
21:38:35  <piscisaureus>way forward
21:39:32  <ryah>whatever that's how it was
21:39:37  <ryah>we'll fix it in the next release
21:39:37  <bnoordhuis>no, but that commit needs work anyway
21:40:31  <CIA-52>libuv: Ben Noordhuis master * rca5346f / (5 files in 2 dirs): unix: revert 98b9f58 and 431195c for now, corrupts memory - http://git.io/M2JpkA
21:41:06  <ryah>i assume we can get a test in libuv which shows this memory problem happening?
21:41:31  <ryah>freeing a stream with a lot of pending writes
21:41:41  <ryah>(we probably need a way to run the tests in valgrind)
21:42:02  <CIA-52>node: Ben Noordhuis master * r86b6bb3 / (4 files in 2 dirs): uv: upgrade to ca5346f - http://git.io/dxDa1Q
21:42:22  <bnoordhuis>we have one, fs-close
21:42:26  <ryah>piscisaureus: another RC please
21:42:27  <bnoordhuis>didn't expose this problem though
21:42:42  <bnoordhuis>*had one, i should say, just backed it out :)
21:42:49  <piscisaureus>ryah: yes working on it
21:43:07  * ryahtopic: the release from hell
21:43:26  <bnoordhuis>haha
21:44:17  <CIA-52>libuv: Bert Belder master * rc4317f6 / uv.gyp : Update uv.gyp after 98b9f58 got reverted - http://git.io/oDDdqQ
21:54:09  <CIA-52>node: Bert Belder master * r11ee7c1 / (deps/uv/uv.gyp deps/uv/test/test-tcp-close.c): Upgrade libuv to c4317f639a - http://git.io/er0EdA
21:55:02  <CIA-52>node: Bert Belder master * r4e63a7e / (deps/uv/uv.gyp deps/uv/test/test-tcp-close.c): Upgrade libuv to c4317f639a - http://git.io/qIGhhA
21:55:24  <ryah>erickt: hey - you had a question about getaddrinfo?
21:55:32  <ryah>erickt: sorry somehow i missed that
21:55:37  <erickt>s'ok :)
21:56:11  <erickt>I noticed that the memset in src/unix/core.c's uv_getaddrinfo isn't really necessary
21:56:23  <bnoordhuis>has anyone seen this?
21:56:24  <bnoordhuis># Fatal error in /home/bnoordhuis/src/nodejs/node/deps/v8/src/handles-inl.h, line 64
21:56:24  <bnoordhuis># CHECK(location_ != __null) failed
21:56:24  <bnoordhuis>#
21:56:24  <bnoordhuis>Command: out/Debug/node /home/bnoordhuis/src/nodejs/node/test/pummel/test-net-pause.js
21:56:39  <bnoordhuis>only seems to happen infrequently :(
21:56:50  <erickt>ryah: if we removed that, then it'd be possible for the user of uv_getaddrinfo to just set the ->data field on their uv_getaddrinfo_t structure directly
21:57:10  <ryah>bnoordhuis: groan - this looks like a v8 bug
21:57:15  <erickt>without needing to add a "void* data" to uv_getaddrinfo()
21:57:33  <piscisaureus>bnoordhuis: no, never
21:57:45  <ryah>erickt: im worried the request will go to the thread pool before the user gets a chance to set it
21:58:12  <ryah>erickt: although - nevermind that's not a worry - the void* data will only be used in the after_cb
21:58:24  <ryah>erickt: which will be handled only after the system goes back to the event loop
21:58:37  <ryah>erickt: so, yes, the void* argument is not necessary
21:58:54  <erickt>ok great :) I'll submit a pull request in a moment :)
22:00:36  <ryah>we're cutting the release despite this bug, bnoordhuis
22:00:49  <bnoordhuis>ryah: sure
22:05:57  * bnoordhuislocks uv_fs_req_cleanup: Assertion `req->ptr' failed.
22:06:03  <piscisaureus>my dns server seems down
22:06:12  <ryah>8.8.8.8
22:09:07  <piscisaureus>uploaded rc3
22:09:27  * piscisaureusoffline for network reset
22:10:14  * piscisaureus_joined
22:10:14  * piscisaureusquit (Read error: Connection reset by peer)
22:10:21  * piscisaureus_changed nick to piscisaureus
22:10:21  * piscisaureusback
22:11:09  <piscisaureus>http://nodejs.org/dist/v0.5.6/node-v0.5.6-rc3.tar.gz
22:12:07  * piscisaureusnot quite in love with being release manager
22:13:20  <ryah>you can see why i want to offload this :)
22:14:48  <piscisaureus>ryah: I am not going to do this every other week
22:14:53  <erickt>ryah: pull request requested: https://github.com/joyent/libuv/pull/182
22:14:58  <ryah>erickt: ok
22:15:01  <piscisaureus>ryah: i am only parttime :-)
22:15:07  <erickt>:)
22:15:09  <piscisaureus>otherwise I will have no time for actual work
22:15:10  <ryah>piscisaureus: it's not usually this bad
22:16:04  <CIA-52>libuv: Ben Noordhuis master * rbd6066c / src/unix/fs.c : unix: fix readdir cleanup assertion - http://git.io/iUWDvg
22:16:10  <bnoordhuis>err... piscisaureus --^
22:18:49  <dmkbot>joyent/libuv: erickt: Subclass uv_getaddrinfo_t from uv_req_t. - https://github.com/joyent/libuv/issues/182
22:22:10  <ryah>piscisaureus: you can leave out bnoordhuis's assert fix if you want - it only happens on failed fs.readdir
22:22:39  <bnoordhuis>and only the sync version at that
22:22:44  <ryah>i think in the intreset of sanity we should move on - unless something more major is found
22:24:40  <CIA-52>node: Bert Belder master * rf9fa6ec / (5 files in 2 dirs): Upgrade libuv to bd6066cb - http://git.io/etMQlw
22:25:08  <ryah>poor bert
22:27:54  <piscisaureus>fuck - force push coming up
22:30:09  <CIA-52>node: Bert Belder master * r0a72ac3 / (7 files in 3 dirs): Upgrade libuv to bd6066cb - http://git.io/GlOqpg
22:30:12  <DrPizza>best kind of push
22:31:37  <bnoordhuis>[12:56|% 100|+ 538|- 22] <- linux
22:32:33  <bnoordhuis>test/pummel/test-timers.js <- always work with release, fails with an assertion error with debug
22:32:45  <bnoordhuis>or rather: assert.AssertionError
22:35:44  * mralephquit (Quit: Leaving.)
22:36:00  <piscisaureus>http://nodejs.org/dist/v0.5.6/node-v0.5.6-rc4.tar.gz
22:36:05  * brsonjoined
22:36:24  <piscisaureus>^ ryah bnoordhuis
22:36:51  <bnoordhuis>bad test, timing sensitive >:(
22:37:59  <ryah>bnoordhuis: yeah - it's a bit hard with timers
22:38:27  * dmkbotquit (Remote host closed the connection)
22:38:47  * dmkbotjoined
22:40:40  <bnoordhuis>anyone testing xp?
22:40:48  <bnoordhuis>xp + mingw, that is
22:42:20  <piscisaureus>bnoordhuis: yeah, I did that
22:42:42  <bnoordhuis>piscisaureus: you're doing the black color thing again
22:43:30  <piscisaureus>Ok, switching to yellow
22:45:10  <ryah>piscisaureus: finally!
22:45:19  <ryah>yellow
22:45:22  <ryah><3
22:46:39  <ryah>piscisaureus: green light on solaris and osx
22:47:08  <piscisaureus>still waiting for windows
22:47:15  <piscisaureus>I assume that is unchanged
22:47:24  <piscisaureus>s/assume/expect/
22:47:31  <ryah>yeah
22:47:33  <bnoordhuis>ryah: you've compiled it on sunos already? how? so fast!
22:47:45  <ryah>bnoordhuis: ccache
22:47:53  <bnoordhuis>ah, that's cheating
22:51:21  <DrPizza>is yellow good or bad
22:51:33  <ryah>piscisaureus: you can prepare the blog post
22:51:57  <piscisaureus>[02:10|% 100|+ 241|- 39]: Done
22:52:03  <piscisaureus>3 down :-(
22:52:21  <piscisaureus>but I don't see tests failing that I think should pass
22:52:28  <piscisaureus>so let's release
22:52:50  <piscisaureus>ryah: let's upload the .exe first
22:52:59  <piscisaureus>someone should try to run it on 2003
22:53:13  * ryahboots 2k3
22:55:04  <ryah>piscisaureus: upload the .exe and i'll try
22:56:13  <igorzi>please upload node.pdb also
22:57:38  <piscisaureus>http://nodejs.org/dist/v0.5.6/node.exe
22:57:44  <piscisaureus>uploading the pdb
22:59:01  <piscisaureus>ryah: I don't know, but piscisaureus is my login name
23:01:31  <ryah>piscisaureus: i can only enable users by email
23:01:38  <piscisaureus>ryah: I am already in
23:02:07  <ryah>ok
23:05:02  <ryah>piscisaureus: win2k3 green light
23:05:08  <piscisaureus>ok good
23:05:20  <ryah>linux also green
23:05:45  <bnoordhuis>[14:04|% 100|+ 532|- 28]: Done <- sunos, slightly better than last time
23:05:53  <piscisaureus>renaming s/-rc4//
23:06:51  <piscisaureus>$ make docs
23:06:52  <piscisaureus>make: *** No rule to make target `docs'. Stop.
23:07:26  <bnoordhuis>piscisaureus: make doc
23:10:53  <ryah>we've got a lot of work ahead of us.
23:12:39  <bnoordhuis>the blog.nodejs.org color scheme is truly awful :/
23:13:07  <bnoordhuis>and that from someone who spends his day in a terminal
23:16:23  <bnoordhuis>hmm, we never give libev the chance to clean up
23:16:42  <bnoordhuis>valgrind complains about reachable but unfree'd memory
23:16:43  <piscisaureus>libuv also doesn't really clean up
23:17:05  <piscisaureus>on windows there's a lot of cruft left when a loop exists, esp. when you have unref()'d
23:17:29  <bnoordhuis>is it worth fixing?
23:17:39  <bnoordhuis>makes tracking down memory leaks harder obviously
23:17:44  <piscisaureus>bnoordhuis: sure, after the release
23:18:12  <piscisaureus>bnoordhuis: if we are serious about multiplicity we have to give people a chance to cleanly destroy a loop
23:18:15  <piscisaureus>and not quit
23:18:40  <bnoordhuis>my thoughts exactly
23:31:29  <ryah>piscisaureus: beautiful
23:34:00  <ryah>piscisaureus: tweet the release with a link to the blog
23:34:20  <CIA-52>node: Bert Belder master * rb49bec5 / (4 files in 3 dirs): Bump version to 0.5.6 - http://git.io/LK52qw
23:34:29  <DrPizza>nice work piscisaureus et al.
23:35:46  * felixgejoined
23:35:46  * felixgequit (Changing host)
23:35:46  * felixgejoined
23:38:19  * felixgequit (Client Quit)
23:38:25  <ryah>great! im taking off
23:38:29  <ryah>good job bert!
23:39:13  <CIA-52>node: Bert Belder master * r0be4812 / src/node_version.h : Now working on v0.5.7 - http://git.io/KCUOtA
23:40:55  <piscisaureus>phew
23:40:57  <piscisaureus>finally
23:42:20  <igorzi>awesome work, piscisaureus
23:42:20  * felixgejoined
23:42:20  * felixgequit (Changing host)
23:42:20  * felixgejoined
23:42:27  <bnoordhuis>congratulations, piscisaureus :)
23:42:56  <piscisaureus>thnx yourself guys.
23:43:05  <piscisaureus>:-)
23:43:21  * felixgequit (Client Quit)
23:45:21  <DrPizza>piscisaureus: as a reward for a job well done, you can do 0.5.7 too
23:45:23  <CIA-52>libuv: Ben Noordhuis master * r52eca75 / include/uv-private/uv-unix.h : unix: uv_pipe_t should not depend on UV_TCP_PRIVATE_FIELDS - http://git.io/Nfv2pA
23:45:23  <CIA-52>libuv: Ben Noordhuis master * reb987bc / (4 files):
23:45:23  <CIA-52>libuv: unix: deduplicate stream init logic
23:45:23  <CIA-52>libuv: Move shared init logic into uv__stream_init(). - http://git.io/edDlKg
23:46:00  <piscisaureus>I'm gonna have a beer.
23:46:19  <bnoordhuis>piscisaureus: are you taking the rest of the night off or do you want to get started on stdio / multicast?
23:46:21  <bnoordhuis>or phode!
23:46:29  <DrPizza>lol phode
23:51:16  <piscisaureus>bnoordhuis: there are bugs to fix.
23:51:25  <piscisaureus>bnoordhuis: but phode :-)
23:51:44  <piscisaureus>bnoordhuis: although I am kinda blocked on the eventemitter. How is that working out?
23:52:08  <bnoordhuis>piscisaureus: oh, i can get HashTable working, it's just kinda cumbersome
23:52:21  <piscisaureus>bnoordhuis: just create an array
23:52:28  <bnoordhuis>oh btw, it's my birthday now
23:52:35  <bnoordhuis>29 :(
23:52:37  <piscisaureus>bnoordhuis: oh, congrats (pie?)
23:52:40  <piscisaureus>w00t
23:52:44  <piscisaureus>29!
23:52:53  <piscisaureus>getting close to ryah
23:52:59  <bnoordhuis>catching up!
23:53:04  <DrPizza>making me feelold
23:53:13  <bnoordhuis>how old are you, peter?
23:53:16  <DrPizza>30 :(
23:53:20  <bnoordhuis>haha
23:53:38  <DrPizza>I am but an empty husk of a man
23:53:42  <DrPizza>well quite a fat empty husk
23:53:46  <bnoordhuis>men get more attractive the more they age
23:53:48  <DrPizza>but empty all the same
23:53:49  <bnoordhuis>i keep telling myself
23:53:55  <DrPizza>I get more spherical the more I age
23:54:00  <DrPizza>and more bald
23:54:02  <DrPizza>these are both good looks!
23:55:55  <igorzi>happy bday, bnoordhuis
23:56:01  <bnoordhuis>thanks, igorzi :)
23:56:12  <bnoordhuis>piscisaureus: i'm going to fix that uv__stream_close() bug first
23:56:33  <piscisaureus>bnoordhuis: I think I will fix test-cli-eval first