00:00:09  * ircretaryjoined
00:06:56  <bnoordhuis>no netdb.h either..
00:13:00  <tjfontaine>bnoordhuis: why don't you understand how unit tests work?
00:20:35  <bnoordhuis>hah, my god
00:26:37  <bnoordhuis>src\uv-common.c(478): error C2196: case value '11001' already used <- interesting...
00:26:57  <bnoordhuis>esp. because mingw has no beef with it
00:33:15  <bnoordhuis>fixed, huzzah!
00:35:02  * amartensjoined
00:40:35  * brsonjoined
00:43:10  * trapitojoined
00:43:21  <trapito>hi
00:45:40  * loladirojoined
00:46:49  <bnoordhuis>trapito: hi
00:49:01  <trapito>please excuse the lame question, but i've written a program in linux using libuv and it works well, now, i tried to compile and run it on osx (switched to clang along the way) and i get an error as soon as i call uv_tcp_connect (ENOTSOCK)
00:49:52  <trapito>i was trying to figure out why would it do such thing but thought about asking before
00:51:18  <bnoordhuis>trapito: could be anything. can you link me to the source?
00:54:36  <trapito>bnoordhuis: http://pastie.org/pastes/8028233/text?key=4m1dbqjxhtegwiapn9ysw
00:56:39  <bnoordhuis>trapito: what is link in global_server_context.geoip_client.base.link?
00:56:51  <bnoordhuis>or rather, what type does it have
01:01:32  <trapito>uv_tcp_t
01:03:56  <bnoordhuis>trapito: hm, okay. not sure then. what do you see with dtruss?
01:04:41  * kazuponjoined
01:04:44  <trapito>didn't use dtruss, it's strange because the whole system works perfectly on linux
01:06:05  <trapito>oh, connect is actually returning the error
01:06:11  <trapito>connect(0x0, 0x7FFF57F9B970, 0x10) = -1 Err#38
01:06:47  <trapito>open("/\0", 0x0, 0xC) = 10 0 << not sure why
01:08:03  <trapito>i wonder if it comes with the gcc -> clang switch
01:08:12  <trapito>i'll check that out
01:15:05  <trapito>ok, same error
01:19:46  <trapito>btw, the open i pasted happens just because of the loop statis if i'm correct, not because of the operation itself
01:24:11  <trapito>uhm, it's quite weird, i've followed the code and didn't see anything weird, also, the assert on top of uv__connect doesn't trigger
01:29:22  <trapito>ugh, kind of found the error but i'm still not sure what could be causing it, maybe_new_socket is exiting on the uv__stream_fd check
01:30:00  * AvianFlujoined
01:33:13  <trapito>definitely found the error
01:35:24  * st_lukejoined
01:36:55  * AvianFluquit (Remote host closed the connection)
01:38:10  * defunctzombiechanged nick to defunctzombie_zz
01:40:40  * AvianFlujoined
01:58:57  <trapito>this is getting weirder and weirder
02:02:40  <trapito>i think it's not code but something else, still not sure about it
02:02:53  <trapito>it's probably something stupid
02:02:58  * kazuponquit (Remote host closed the connection)
02:03:06  <bnoordhuis>trapito: try to trim it down to a standalone test case
02:03:36  <bnoordhuis>if you post it in an issue, i'll take a look at it tomorrow
02:04:15  * abraxasjoined
02:07:26  * kazuponjoined
02:24:14  * brsonquit (Quit: leaving)
02:28:26  * bnoordhuisquit (Ping timeout: 255 seconds)
02:44:26  * c4milojoined
02:46:05  * trapitoquit (Quit: Page closed)
02:50:46  * qardjoined
03:02:52  * st_lukequit (Remote host closed the connection)
03:12:50  * AvianFluquit (Remote host closed the connection)
03:16:31  * qardquit (Quit: Leaving.)
03:30:57  * groundwaterjoined
03:34:08  * bnoordhuisjoined
03:36:34  * c4miloquit (Remote host closed the connection)
03:39:16  * bnoordhuisquit (Ping timeout: 276 seconds)
03:52:51  * kazuponquit (Remote host closed the connection)
03:54:48  * AvianFlujoined
04:17:14  * olalondequit (Quit: olalonde)
04:32:04  * timoxleyjoined
04:37:52  * defunctzombie_zzchanged nick to defunctzombie
04:43:25  * defunctzombiechanged nick to defunctzombie_zz
04:49:25  * groundwaterquit (Quit: groundwater)
04:53:11  * kazuponjoined
04:57:54  * kazuponquit (Ping timeout: 240 seconds)
04:59:04  * kazuponjoined
05:11:22  * kazuponquit (Remote host closed the connection)
05:12:57  * kazuponjoined
05:28:23  * mikealjoined
05:30:56  * bajtosjoined
05:32:39  * paddybyersjoined
05:32:49  * mikealquit (Ping timeout: 248 seconds)
05:32:49  * pooyajoined
05:32:50  * wmiljoined
05:34:51  * loladiroquit (Quit: loladiro)
05:38:59  * mikealjoined
05:53:19  * defunctzombie_zzchanged nick to defunctzombie
06:02:49  * defunctzombiechanged nick to defunctzombie_zz
06:04:19  * AvianFluquit (Remote host closed the connection)
06:16:08  * paddybyersquit (Ping timeout: 255 seconds)
06:23:23  * defunctzombie_zzchanged nick to defunctzombie
06:31:33  * defunctzombiechanged nick to defunctzombie_zz
06:35:57  * wmilquit (Remote host closed the connection)
06:37:10  * defunctzombie_zzchanged nick to defunctzombie
06:39:39  * defunctzombiechanged nick to defunctzombie_zz
06:40:03  * `3rdEdenjoined
06:45:40  * bajtosquit (Quit: bajtos)
06:50:13  * paddybyersjoined
06:51:12  * rendarjoined
06:54:01  * wmiljoined
06:54:23  * paddybyersquit (Ping timeout: 240 seconds)
06:54:44  * bajtosjoined
07:05:43  * wmilquit (Remote host closed the connection)
07:14:27  * paddybyersjoined
07:35:14  * csaohjoined
08:05:33  * philips_quit (Ping timeout: 245 seconds)
08:09:18  * csaohquit (Ping timeout: 245 seconds)
08:15:29  * csaohjoined
08:22:55  * olalondejoined
08:23:55  * csaoh_joined
08:24:31  * csaohquit (Ping timeout: 264 seconds)
08:24:31  * csaoh_changed nick to csaoh
08:28:53  * csaohquit (Ping timeout: 245 seconds)
08:29:38  * csaohjoined
08:39:05  * amartensquit (Quit: Leaving.)
08:39:21  * timoxleyquit (Quit: Computer has gone to sleep.)
08:56:58  * timoxleyjoined
08:57:54  * bnoordhuisjoined
08:58:05  * dominictarrjoined
09:44:45  * dominictarrquit (Quit: dominictarr)
10:05:44  * dominictarrjoined
10:18:03  * dominictarrquit (Quit: dominictarr)
10:24:34  * kazuponquit (Remote host closed the connection)
10:28:09  * timoxleyquit (Quit: Computer has gone to sleep.)
10:29:26  * csaohquit (Quit: csaoh)
10:36:40  * abraxasquit (Remote host closed the connection)
10:43:31  * csaohjoined
10:44:30  * bnoordhuisquit (Ping timeout: 264 seconds)
10:51:51  * dominictarrjoined
11:12:56  * bajtosquit (Quit: bajtos)
11:47:21  * bajtosjoined
11:50:30  * bnoordhuisjoined
11:54:59  * bnoordhuisquit (Ping timeout: 255 seconds)
11:56:14  * olalondequit (Quit: olalonde)
11:58:17  * hzjoined
12:02:24  * hzquit (Ping timeout: 240 seconds)
12:03:00  * timoxleyjoined
12:04:49  * hzjoined
12:36:57  * abraxasjoined
12:41:23  * abraxasquit (Ping timeout: 240 seconds)
13:02:12  * philipsjoined
13:08:19  * c4milojoined
13:16:23  * hzquit (Ping timeout: 240 seconds)
13:31:10  * hzjoined
13:32:43  * bajtosquit (Quit: bajtos)
13:39:17  * hzquit (Read error: Connection reset by peer)
13:40:41  * hzjoined
13:41:23  * timoxleyquit (Ping timeout: 245 seconds)
13:41:29  * AvianFlujoined
13:51:14  * papertigersjoined
13:51:33  * loladirojoined
13:53:37  * bnoordhuisjoined
14:06:16  * pachetjoined
14:11:28  * bajtosjoined
14:28:24  * c4miloquit (Remote host closed the connection)
14:32:00  * pooyaquit (Quit: pooya)
14:33:12  * leonvvjoined
14:33:19  * pooyajoined
14:34:36  * c4milojoined
14:44:06  * mikealquit (Quit: Leaving.)
14:47:48  * defunctzombie_zzchanged nick to defunctzombie
14:50:12  * bajtosquit (Quit: bajtos)
14:56:45  * pachet_joined
14:58:53  * pachetquit (Ping timeout: 240 seconds)
15:06:56  * wmiljoined
15:11:24  * bajtosjoined
15:11:38  * wmilquit (Ping timeout: 255 seconds)
15:12:23  <trevnorris>morning
15:19:07  * leonvvquit (Remote host closed the connection)
15:24:31  * groundwaterjoined
15:27:56  * pachet_quit (Quit: leaving)
15:28:11  * timoxleyjoined
15:29:42  * bajtosquit (Quit: bajtos)
15:32:55  * bnoordhuisquit (Ping timeout: 264 seconds)
15:44:35  * HenryRjoined
15:46:55  * dapjoined
15:48:44  * loladiroquit (Quit: loladiro)
16:02:05  <trevnorris>isaacs: ping
16:02:38  <tjfontaine>good day good sirs
16:02:44  <trevnorris>hey hey
16:09:34  * juliangruberquit (Ping timeout: 256 seconds)
16:09:37  * bajtosjoined
16:10:43  * mmaleckiquit (Ping timeout: 264 seconds)
16:10:52  * juliangruberjoined
16:10:53  * mmaleckijoined
16:16:02  * loladirojoined
16:19:04  * Benviejoined
16:22:10  * dominictarrquit (Quit: dominictarr)
16:28:00  * c4miloquit (Remote host closed the connection)
16:38:29  * bnoordhuisjoined
16:40:38  * csaohquit (Quit: csaoh)
16:41:14  <trevnorris>how do you disable -Werror at compile time? always forget the param
16:41:51  <tjfontaine>you mean -Wno-error
16:42:39  <trevnorris>ah yeah. forgot to set my *FLAGS
16:43:18  * bnoordhuisquit (Ping timeout: 264 seconds)
16:43:21  * amartensjoined
16:52:57  * timoxleyquit (Quit: Computer has gone to sleep.)
16:57:31  * pooyaquit (Quit: pooya)
16:58:10  * `3rdEdenquit (Remote host closed the connection)
17:06:20  * mikealjoined
17:07:46  <trevnorris>tjfontaine: have a moment, and a linux box?
17:08:17  <tjfontaine>what's up?
17:08:45  <tjfontaine>#5181?
17:08:54  <trevnorris>i'm getting some strange ass stuff. first, i'm getting a segfault on tip of v0.8 branch running #5015 OP's code.
17:09:01  <trevnorris>yeah, and 5181.
17:09:15  * c4milojoined
17:09:20  <trevnorris>just want to see if someone else is crashing as well.
17:10:04  <tjfontaine>so you want me to test v0.8 HEAD on linux?
17:10:32  <trevnorris>tjfontaine: yeah, running the OP's code from 5015. I can't figure out why it's crashing.
17:10:55  <tjfontaine>when you say OP you mean Original Poster?
17:10:56  <trevnorris>tjfontaine: thing is both crashes are occurring around the time node is exiting. which doesn't make sense.
17:10:59  <trevnorris>yeah :)
17:12:20  <trevnorris>but I can't get either to crash w/ a Debug build. which is really annoying.
17:14:16  <trevnorris>whoa. don't do (gdb) p <TAB> <TAB>
17:14:39  <tjfontaine>heh there are a lot of symbols
17:14:42  * brsonjoined
17:15:48  <trevnorris>tjfontaine: ok, it must be something w/ my machine. i'm seg faulting on a build I know used to work. going to restart my box.
17:17:24  * piscisaureus_joined
17:19:09  * AvianFluquit (Remote host closed the connection)
17:21:41  <tjfontaine>trevnorris: it's working here
17:22:04  <trevnorris>tjfontaine: well. restarting didn't fix it. i'm still seg faulting.
17:22:48  <tjfontaine>I did 100 iterations without fail
17:23:13  * paddybyersquit (Ping timeout: 248 seconds)
17:23:49  <trevnorris>tjfontaine: just so you know i'm not crazy: https://gist.github.com/trevnorris/5750606
17:24:55  <tjfontaine>I have no problem believing you're seeing a segfault, I just can't reproduce it :)
17:25:34  <trevnorris>thanks for trusting me. :)
17:26:32  <trevnorris>tjfontaine: so that's happening on the tip of both v0.8 and v0.10, but I can't reproduce on master.
17:26:48  <tjfontaine>trevnorris: I guess based on that backtrace you can turn on some v8 options and see where the optimizer is killing you
17:27:18  <trevnorris>true. now to figure out which options those are.
17:27:26  <tjfontaine>--trace-deopts at the very least
17:27:40  <tjfontaine>but it's odd that this is happening during shutdown
17:27:49  <trevnorris>yeah, right.
17:27:55  <trevnorris>it's after everything's run properly.
17:28:05  * pachetjoined
17:28:05  * pachetquit (Changing host)
17:28:05  * pachetjoined
17:28:13  <tjfontaine>in context.dispose no less
17:28:41  <tjfontaine>could be a miscompile I guess
17:29:16  <trevnorris>tjfontaine: oh shit. yeah. I just upgraded to clang 3.3
17:29:17  * TooTallNatejoined
17:29:41  <tjfontaine>trevnorris: if you have gcc or older clang give them a shot
17:31:12  <trevnorris>wow. hard core brain fart. can't remember the vars to set to compile w/ gcc.
17:31:31  <trevnorris>nm
17:35:06  <trevnorris>tjfontaine: yup.
17:35:49  <tjfontaine>ok, so we'll need some fun debugging skills to try and figure that one out
17:36:27  <trevnorris>tjfontaine: well, it's not happening in master. do we want to say that v0.10 just supports 3.2?
17:36:41  <trevnorris>(mainly because this just sounds like a world of hurt)
17:36:48  * chilts_joined
17:37:41  <trevnorris>tjfontaine: well, actually what's strange is that it doesn't always occur. just sometimes. haven't been able to figure out the criterion for it to happen.
17:38:14  <tjfontaine>trevnorris: it's probably related to the v8 version + clang + compiler optimizations turned on
17:38:25  <trevnorris>yeah
17:38:31  <tjfontaine>trevnorris: so you can start by tweaking those like start with -O0 and work back up to where we are
17:39:11  <tjfontaine>if we can reproduce at -O0 then we're really in good shape to track it down (though seems unlikely because of debug build not failing)
17:39:29  <trevnorris>well, it's not happening in Debug builds
17:39:35  <tjfontaine>that's what I said
17:39:44  <tjfontaine>chances are we can track it down to a specific optimization that we can disable
17:39:52  <trevnorris>heh, typing too many places at once. :)
17:40:11  <trevnorris>ok, if it's from an optimization and not from a race condition then it'll be a lot easier.
17:40:16  <trevnorris>lemme try something.
17:40:51  <tjfontaine>release builds at -O0..3 will probably indicate if it's an optimization miscompile
17:41:35  * skebcio_joined
17:42:24  * mikealquit (*.net *.split)
17:42:25  * bajtosquit (*.net *.split)
17:42:29  * skebcioquit (*.net *.split)
17:42:34  * chiltsquit (*.net *.split)
17:42:37  * tellnesquit (*.net *.split)
17:43:40  <tjfontaine>"you're scripts might"
17:43:40  <tjfontaine>heh
17:44:58  * tellnesjoined
17:46:12  <trevnorris>tjfontaine: updated 5657 w/ some strace output.
17:46:26  <trevnorris>but i'm still new at reading all that. :)
17:48:20  <tjfontaine>sure, but your gdb backtrace is the most useful
17:49:35  <trevnorris>yeah. i'm just throwing every cpp debugging skill I have at it (which aren't many :P
18:00:45  <trevnorris>tjfontaine: fwiw, ran strace -f, last command is madvise(..., ..., MADV_DONTNEED)
18:00:50  <trevnorris>followed by exit(0)
18:01:04  <trevnorris>then get a process detached.
18:04:49  <tjfontaine>have you done the -O0 tests yet?
18:06:41  <trevnorris>tjfontaine: you mean besides a straight up Debug build?
18:06:55  <tjfontaine>yes, more htan just the debug build
18:07:00  <trevnorris>ok
18:07:06  <trevnorris>i'll step through em
18:10:54  <trevnorris>tjfontaine: ok. only happens w/ -O2
18:11:12  <tjfontaine>ok that's good
18:11:36  <tjfontaine>so basically just want to see the difference optimizations enabled between the two
18:12:01  <trevnorris>tjfontaine: ok. so from the strace output. a futext is resuming after the process has detached.
18:12:07  <trevnorris>think that's a thread race?
18:12:41  <trevnorris>ah yeah. PID 28580 is resuming a futex, and 28581 is detaching the process.
18:13:00  <trevnorris>and they just happen to overlap
18:16:13  * EhevuTovjoined
18:17:13  <trevnorris>isaacs out today?
18:23:23  <tjfontaine>I believe he has yoga in the morning now
18:23:28  <trevnorris>heh, cool
18:24:26  <trevnorris>and bnoordhuis must be hiding from me. promised a review last week. :P
18:25:13  <trevnorris>piscisaureus_: feel like reviewing some code. :)
18:29:13  * AvianFlujoined
18:31:04  * brsonquit (Ping timeout: 276 seconds)
18:44:23  * brsonjoined
18:49:15  * mikealjoined
18:54:04  * mraleph1joined
18:54:10  * mralephquit (Read error: Connection reset by peer)
18:56:01  * HenryRawasjoined
18:56:09  * HenryRquit (Read error: Connection reset by peer)
19:12:37  * piscisaureus_quit (Ping timeout: 248 seconds)
19:14:56  <trevnorris>anyone? anyone?
19:15:06  * trevnorrissees a tumbleweed roll by
19:46:17  * txdvquit (Read error: Operation timed out)
19:46:28  * piscisaureus_joined
20:05:44  * bnoordhuisjoined
20:07:28  * EhevuTov_joined
20:10:45  * EhevuTovquit (Ping timeout: 248 seconds)
20:13:19  <isaacs>fg
20:13:24  <tjfontaine>wb
20:15:30  <trevnorris>isaacs: you're alive!
20:16:21  <isaacs>yep
20:16:42  <isaacs>i have been kinda heads down trying to finish this email change security feature for npmjs.org
20:17:06  <isaacs>step 2 of my ridiculously circuitous plan to implement package signing in such a way that everyone actually does it.
20:17:11  * piscisaureus_quit (Ping timeout: 255 seconds)
20:17:56  <trevnorris>heh, sounds like a challenge.
20:18:15  <bnoordhuis>isaacs: what's your scheme?
20:18:21  <tjfontaine>to take over the world
20:18:28  <trevnorris>isaacs: fyi, got external strings working: 5641
20:18:34  <isaacs>trevnorris: ad :)
20:18:36  <isaacs>*rad
20:18:53  <isaacs>bnoordhuis: so, the idea is, package signing should save us, even if the user's account is hijacked, yes?
20:18:57  <isaacs>but where do you store the pubkeys?
20:19:17  <isaacs>it is completely unreasonable to use PGP keys, and put them in MIT or some other public keyserver.
20:19:31  <isaacs>they're all super slow, and it's Yet Another thing that can go down and then you're as good as if you didn't have keys.
20:19:52  <isaacs>putting them in your npm account is ok, but if i have your password, why don't i just add my key to your account?
20:20:14  <isaacs>so, to mitigate that risk, whenever a key is added to the account, it emails you to say that this happened, and let you revert it.
20:20:27  <bnoordhuis>right, makes sense
20:20:31  <isaacs>so, now, if i have your password, i have to change your email address, and then add my key.
20:20:38  <trevnorris>isaacs: no idea how this could work, but could you enforce adding keys by using a key already in the account?
20:20:51  <isaacs>to mitigate THAT risk, email can only be changed by admins
20:21:10  <isaacs>to chnage your email address, you request the change, 2 tokens are minted. one to the new address to confirm the change, and one to the old address to revert it.
20:21:53  <bnoordhuis>circuitous indeed :)
20:22:04  <bnoordhuis>the plan is to have everyone use gpg?
20:22:14  <trevnorris>here's an insane idea. key store is a git repo. remote doesn't allow force push. each commit must be signed by a key who's public is in the repo.
20:22:36  <trevnorris>then only existing keys can add new keys.
20:22:38  <isaacs>so now, if i steal your account password, i have to request an email change, AND not get reverted, and i think at that point, while we're not at the KGB/CIA level of security, it's enough for our dumb little package manager webapp thingie
20:22:44  <isaacs>bnoordhuis: the plan is for everyone to use ssh keys.
20:22:51  <isaacs>bnoordhuis: gpg is too unix-only
20:23:01  <bnoordhuis>yeah, and a pain to set up
20:23:02  <isaacs>bnoordhuis: but github has already gotten everyone to have ssh keys.
20:23:12  <tjfontaine>there is that js implementation of it, brr
20:23:14  <isaacs>bnoordhuis: and then we can have a "Login with github to import your keys"
20:23:35  <isaacs>and, i mean, with gpg, you still have all the same problems with key storage.
20:23:37  <creationix>ssh in js isn't bad
20:23:44  <creationix>especially since node exports rsa primitives
20:23:56  <isaacs>we can do signing and verifying using ssh keys in node already with the crypto stuff.
20:24:00  <isaacs>that part is actually pretty easy
20:24:02  <tjfontaine>creationix: I was actually referring to the gpg implementation
20:24:10  <isaacs>the tricky bit was decoding passphrase-encrypted keys.
20:24:12  <isaacs>but i did that.
20:24:46  <isaacs>this could also set the stage for a "login to couchdb with your ssh keys" feature, or a "publish over ssh" feature.
20:24:49  <isaacs>i dunno
20:24:54  <isaacs>pie in the sky thinking, there
20:25:12  <creationix>well, if you need any custom git stuff, I may be able to help out
20:26:43  <isaacs>creationix: actually, luk brought up the idea of using js-git for the places where npm shells out to the git executable.
20:26:57  <isaacs>creationix: i kinda shrugged. for my purposes, shelling out to git is actually pretty ok
20:26:57  <creationix>so I have code today if you just want to get the files
20:27:02  <creationix>clone at a tag or branch
20:27:19  <creationix>I haven't added shallow clone yet, but it shouldn't be much harder (if desired)
20:27:59  <creationix>I guess the value is for windows users (or anyone really) who installs node, but not git
20:28:02  <creationix>git is a little harder to get
20:31:20  <trevnorris>bnoordhuis: any smalloc lately? ;-)
20:32:34  <trevnorris>bnoordhuis: and thanks for the 5641 review. did manage to get that into a template class.
20:33:36  <trevnorris>isaacs: oh, and interestingly. binary encoding went from the slowest to now the fastest.
20:33:55  <trevnorris>and by a hefty margin for anything over 8kb
20:34:28  <isaacs>trevnorris: nice
20:34:49  * isaacsforesees a day when we abandon buffers and return to binary strings...
20:35:29  <trevnorris>....
20:35:38  <creationix>though binary strings still use twice the ram?
20:35:44  <creationix>or does v8 optimize them?
20:36:42  <isaacs>creationix: that's another problem we'll have to solve :)
20:36:56  <trevnorris>this is a problem i'm not familiar with.
20:37:09  <isaacs>creationix: that was like a dreamy unrealistic "foresee", not a "this will happen tomorrow" kind
20:37:39  <creationix>isaacs: tomorrow would be insane :P
20:37:53  <creationix>or even "next major release"
20:38:15  <trevnorris>isaacs: well, technically it's possible to convert any Buffer to a binary string fairly cheaply (using external strings)
20:38:35  <trevnorris>and back
20:38:47  <creationix>trevnorris: so buffer.toString('binary') and new Buffer(string, 'binary')?
20:39:18  <creationix>I assume the "and back" part is only fast for actual external strings
20:39:27  <trevnorris>creationix: sort of. right now for any buffer < 0xfbee9 it's copied into the v8 heap.
20:39:50  <trevnorris>creationix: this impl would explicitly use the external data
20:40:01  * EhevuTov_quit (Quit: This computer has gone to sleep)
20:40:09  <trevnorris>creationix: though the strange strange thing is that using external strings means you can also create mutable strings in v8
20:40:14  <trevnorris>(on the js side)
20:41:29  <trevnorris>been playing around w/ them, and you can sort of create a view into the buffer as a binary string, and the contents can change as you manipulate the buffer.
20:41:57  <creationix>trevnorris: that can't be good for v8
20:42:36  <trevnorris>creationix: can you define "[not] good for"
20:42:50  <creationix>doesn't it make assumptions on the fact that strings are immutable
20:43:03  <creationix>so you might get cached old data sometimes
20:43:59  <trevnorris>not as far as I know. they're treated more or less the same as the data attached to an array buffer
20:44:18  <creationix>I guess that makes sense
20:44:27  <creationix>can't think of any meaningful optimization it would make
20:44:30  <trevnorris>just external memory attached to a js object. except in this case it's interpreted into a string instead of a data array.
20:44:43  <trevnorris>oh. no idea if it's even useful.
20:44:49  <trevnorris>just wanted to see if it was possible. :)
20:45:36  <trevnorris>creationix: though there is a crazy cliff when writing in strings. so much I filed a bug: http://code.google.com/p/v8/issues/detail?id=2721
20:46:18  * piscisaureus_joined
20:47:19  <creationix>I see
20:47:55  <trevnorris>bnoordhuis: also, might interest you. seems there are cases in node ( >= v0.10.x) compiled w/ clang 3.3 where there's a thread race closing the process: 5657
20:49:08  <bnoordhuis>trevnorris: are you sure it's a node bug, not a v8 bug?
20:50:34  <tjfontaine>I think it's v8+clang3.3
20:51:00  <tjfontaine>and actually a miscompile seems more likely since it goes away with -O1
20:54:54  <trevnorris>bnoordhuis: could be. still trying to create a v8 stand alone test that reproduces the error.
20:56:05  <tjfontaine>does `node -e ''` crash as well?
20:56:38  * AvianFlu_joined
20:58:17  * AvianFluquit (Ping timeout: 245 seconds)
20:58:37  * othiym23quit (*.net *.split)
20:58:38  * felixgequit (*.net *.split)
20:58:39  <trevnorris>sec
20:58:43  * felixgejoined
20:58:43  * felixgequit (Changing host)
20:58:43  * felixgejoined
20:59:18  * othiym23joined
21:00:46  * EhevuTovjoined
21:01:59  <trevnorris>tjfontaine: this will: ./node -e "for(var i = 0; i < 1e3; i++) require('crypto').createHash('md5').update('a').digest();"
21:02:18  <trevnorris>that's on latest v0.10
21:02:34  <tjfontaine>trevnorris: trying to establish the minimum, so I guess '' doesn't fail?
21:03:04  <trevnorris>tjfontaine: no. but if I run "make test" then a certain subset fail.
21:03:13  <trevnorris>i'll run though those and see if I can find a minimal case.
21:03:30  <tjfontaine>what about just making a large buffer in the eval
21:04:06  <bnoordhuis>trevnorris: did clang print any warnings when building node / v8?
21:04:32  <bnoordhuis>btw, are you testing with a release version of clang or is it from svn/git?
21:05:09  <trevnorris>bnoordhuis: i built it, but it's from their release_33
21:05:51  <trevnorris>bnoordhuis: oh hell. ok yeah. that's the release branch, but they haven't created the actual release tag.
21:08:07  <trevnorris>tjfontaine: this will seg fault: ./node -e "for (i=0;i<1e3;i++) new Buffer(0xf);"
21:09:08  <tjfontaine>right
21:09:47  <trevnorris>bnoordhuis: ok. so is this a non-issue since 3.3 hasn't been officially released?
21:10:05  <tjfontaine>if it is a miscompile we'll want to tell them asap
21:10:20  <tjfontaine>especially since I would expect it to be released shortly as part of the new xcode for ios7
21:10:50  <trevnorris>it doesn't happen on latest v8, only 3.14 or before. not sure what that means though
21:13:17  * mikealquit (Ping timeout: 252 seconds)
21:13:33  * mikealjoined
21:14:20  <trevnorris>i'm trying to figure out what caused which threads to spawn.
21:15:44  <trevnorris>any tips here? last time I found a bug in clang, bnoordhuis was actually the one that figured it out. :)
21:16:46  <trevnorris>it's easily reproducible, and always fails the same way.
21:17:07  <trevnorris>one thread exits the process while another is in the middle of resuming a futex.
21:17:32  <tjfontaine>look at the differences in the optimizations enabled/disabled, compile with O1 and enable each one, find the offending pass (hopefully its just one and not a combination) and then you can compare the assembly around the failure
21:17:59  <tjfontaine>presuming you can't just eyeball the assembly around the failure right now and see the problem
21:19:56  <trevnorris>tjfontaine: ah hell. ok so I have no idea how to read strace output.
21:20:04  * defunctzombiechanged nick to defunctzombie_zz
21:20:15  <trevnorris>tjfontaine: just did the same and the calls are exactly the same, except the good one just continues w/ a mmap call
21:20:18  <tjfontaine>I'm not convinced the strace output is helping you anyway
21:20:26  <trevnorris>yeah...
21:20:32  * dannycoatesjoined
21:21:01  <trevnorris>so.... what's a good tool for examining the assembly (sorry, i'm entering total newbish area)
21:21:17  <bnoordhuis>trevnorris: gdb disassemble/m
21:21:25  <trevnorris>thanks :)
21:21:29  <tjfontaine>gdb can do it, basically you want to break in the function that's failing but in the clean path with O1
21:21:58  <bnoordhuis>you don't even have to break
21:22:04  <tjfontaine>sure
21:22:18  <tjfontaine>anyway ben can help you :)
21:24:00  * qardjoined
21:24:49  * qardpart
21:25:10  * papertigersquit (Ping timeout: 246 seconds)
21:38:36  <bnoordhuis>pummel/test-regress-GH-892 is borked in v0.10
21:38:42  <bnoordhuis>(node) warning: Recursive process.nextTick detected. This will break in the next version of node. Please use setImmediate for recursive deferral.
21:38:45  <bnoordhuis>RangeError: Maximum call stack size exceeded
21:38:48  <bnoordhuis>got 22216601 bytes
21:38:58  <bnoordhuis>deja vu, i remember bringing this up
21:40:05  <trevnorris>i feel like a big kid now. examining the disassembly of cc functions and all. :)
21:40:36  <tjfontaine>pummels are all kinds of fubard
21:41:09  * EhevuTovquit (Quit: This computer has gone to sleep)
21:41:10  * c4miloquit (Remote host closed the connection)
21:43:05  * rendarquit
21:43:23  <trevnorris>tjfontaine: so. the assembly of -O1 and -O2 aren't that close.
21:44:09  <tjfontaine>optimizations can do a lot of crazy things
21:44:21  <tjfontaine>whcih is why it's easier to try and identify a single optimization that triggers it
21:44:28  * AlbireoX_joined
21:44:40  <trevnorris>yeah. and it's a lot of crazy. i'm just going to break on it and step through each machine instruction
21:44:49  <tjfontaine>so look at which optimizations that O2 enables that O1 doesn't, and try one by one to compile node and see which causes it to fail
21:44:51  * papertigersjoined
21:45:29  <trevnorris>i know you're speaking english, but to me -O2 == "magic that makes things go faster"
21:45:41  <trevnorris>i didn't realize you could break apart each optimization.
21:48:29  <tjfontaine>"Try using the -debug-pass=Arguments options to see what passes are being run at each optimization level. "
21:49:08  <tjfontaine>hm that may not be valid for clang but only for llvm
21:49:24  <tjfontaine>ah there we go, wit -mllvm
21:50:03  <tjfontaine>https://gist.github.com/tjfontaine/5752706
21:50:15  <tjfontaine>shows on my clang the difference optimizations being enabled at each pass
21:50:22  <trevnorris>interesting. thanks. :)
21:51:20  <tjfontaine>anyway #llvm on oftc can offer plenty more advice on tracking it down
21:51:27  <trevnorris>ok. found the instruction that fails, no idea how to interpret it: "<_ZN2v88internal15MemoryAllocator4FreeEPNS0_11MemoryChunkE+64>: mov 0xd(%rax),%cl"
21:53:37  * defunctzombie_zzchanged nick to defunctzombie
21:55:42  * kevinswiberjoined
21:58:02  <trevnorris>tjfontaine: ok. so in your opinion i'll find the issue much quicker if I figure out how to check each pass arguments for the method that's failing?
21:58:13  * mikealquit (Quit: Leaving.)
21:58:58  * chilts_changed nick to chilts
21:59:38  <tjfontaine>trevnorris: it's suspect that it works fine at O1 and fails at O2, so there's likely an optimization being greedy and throwing away information that it needs
21:59:45  * papertigersquit (Quit: papertigers)
22:00:02  <trevnorris>tjfontaine: oh. so you're saying check the differences between the two optimizations.
22:00:07  <tjfontaine>yes.
22:00:21  * EhevuTovjoined
22:00:22  <tjfontaine>start with O1, and then add the first missing optimization
22:00:27  <trevnorris>ok. in that case i'm just going to go compile v8 instead of all of node.
22:00:49  <tjfontaine>best if you can get a standalone test case for d8 as well then
22:00:58  <tjfontaine>so you can do a small script to work through the permutations
22:01:25  <trevnorris>yeah. still haven't been able to figure that out.
22:02:24  * mikealjoined
22:02:42  <tjfontaine>trevnorris: it feels like you just need to have the gc suitably primed with data and then let it exit
22:02:58  <trevnorris>hm. true. ok, I'll give that a go.
22:03:23  <tjfontaine>but it may be that it's the method optimization cache that needs to be primed
22:07:19  <bnoordhuis>trevnorris: print $rax
22:08:07  <bnoordhuis>"mov 0xd(%rax),%cl" means "move the byte that's at position $rax+0xd into %cl", the low 8 bits of %rcx
22:16:27  <trevnorris>bnoordhuis: tried to trace that register through the entire method: https://gist.github.com/trevnorris/5752902
22:18:30  <bnoordhuis>trevnorris: did you use disassemble/m? it prints source + disassembly
22:18:51  <trevnorris>oh. spaced the /m. sec
22:22:18  <trevnorris>bnoordhuis: sorry, couple clarifications. should I be running this on the build that fails, or on a debug build? and do I run disassemble/m on the frame that fails?
22:23:37  <trevnorris>sorry again. once I get what i'm actually looking for won't need all the hand holding. :)
22:25:13  <bnoordhuis>trevnorris: on both builds and like this: disassemble/m <name_of_function_that_fails>
22:25:21  <trevnorris>cool. can do
22:25:40  <bnoordhuis>then just put them side-by-side and check the differences
22:27:30  * c4milojoined
22:35:04  <trevnorris>bnoordhuis: so there's one thing that sticks out that's removed before the failing instruction runs:
22:35:04  <trevnorris>callq 0x848e20 <_ZNK2v88internal11MemoryChunk5ownerEv>
22:36:33  <trevnorris>and the line that follows:
22:36:34  <trevnorris>test %rax,%rax
22:36:40  <bnoordhuis>that's missing from the optimized build?
22:36:54  <trevnorris>yeah
22:37:05  <trevnorris>they're here: https://gist.github.com/trevnorris/5752992
22:37:06  <bnoordhuis>the "test %rax,%rax" is a return_value==0 check btw
22:37:13  <trevnorris>ah, ok :)
22:37:54  <trevnorris>in -O1.out line 21
22:38:39  <bnoordhuis>apparently clang thinks chunk->owner() is never NULL
22:38:56  * kevinswiberquit (Remote host closed the connection)
22:40:33  <trevnorris>so, how do you know it's checking NULL?
22:42:17  <bnoordhuis>because that's what the "test %rax,%rax" corresponds with, right?
22:42:49  * trevnorrisgoes looking for his assembly instructions manual
22:43:14  * dominictarrjoined
22:43:49  * kevinswiberjoined
22:44:03  <bnoordhuis>trevnorris: anyway, if that's what it's doing, then it's a clang bug
22:44:35  <bnoordhuis>looking at your asm dump, it seems clang altogether optimizes away the call to chunk->owner()
22:45:06  <trevnorris>bnoordhuis: ah ok. so "test %rax,rax" followed by "je ..." means to jump past the instructions.
22:46:22  <bnoordhuis>trevnorris: oh wait, maybe not
22:46:23  * EhevuTov_joined
22:46:30  <bnoordhuis> 0x00000000008520af <+47>: mov 0x40(%r14),%rax
22:46:30  <bnoordhuis> 0x00000000008520b3 <+51>: mov %rax,%rcx
22:46:30  <bnoordhuis> 0x00000000008520b6 <+54>: and $0x3,%rcx
22:46:31  <bnoordhuis> 0x00000000008520ba <+58>: cmp $0x3,%rcx
22:46:42  <bnoordhuis>that looks like an inlined version of chunk->owner()
22:47:25  <bnoordhuis>so never mind what i said :)
22:47:37  <trevnorris>ah ok. see it now.
22:49:39  * EhevuTovquit (Ping timeout: 256 seconds)
22:50:15  * kazuponjoined
22:50:31  <trevnorris>well, whatever. i'll keep poking at it. bnoordhuis your library of knowledge is better elsewhere. thanks for all the debugging tips. :)
22:52:09  <bnoordhuis>no problem :)
22:52:42  <tjfontaine>sigh. path.js should really let the user normalize for a specific platform
22:53:48  * kevinswiberquit (Remote host closed the connection)
23:01:25  * mikealquit (Quit: Leaving.)
23:02:05  * defunctzombiechanged nick to defunctzombie_zz
23:02:27  * piscisaureus_quit (Ping timeout: 245 seconds)
23:04:06  * mikealjoined
23:04:32  <trevnorris>tjfontaine: so are you or is indutny working on the "short circuit" of stream_wrap converting data to a Buffer?
23:05:03  * pachetquit (Quit: leaving)
23:05:45  <tjfontaine>trevnorris: we've both done a mechasim for it
23:05:56  <trevnorris>tjfontaine: coolio. I want to see!
23:06:29  <bnoordhuis>signing off. have a good night, guys
23:06:34  <trevnorris>night
23:06:34  <tjfontaine>the start of what I did https://github.com/tjfontaine/node/commit/a7b88e691a4961611ca45013d0a67b5ce639d4e3
23:09:01  <tjfontaine>https://github.com/indutny/node/commit/67be8ed1ae65563e5a5374d4bad51bc1e6917cfc looks like the start of indutny's
23:09:38  <trevnorris>tjfontaine: awesome. if my first set of buffer patches get in then i'll be able to move on removing the slab allocator.
23:09:50  <trevnorris>already have those patches ready, waiting for the first ones to be reviewed.
23:11:12  * bnoordhuisquit (Ping timeout: 256 seconds)
23:11:33  <tjfontaine>trevnorris: so one of the side effects of this would be that you don't necessarily need to rip out the slab allocator entirely, you could just override Alloc/Shrink in your descendent class
23:12:08  <trevnorris>tjfontaine: well, the slab allocator removal is for performance and stability.
23:12:19  <trevnorris>and to remove the memory leaks that users keep complaining about.
23:12:26  <tjfontaine>"leaks"
23:13:05  <trevnorris>the gotcha that devs hang onto a chunk of the request Buffer, which forces the entire slab to stick around.
23:13:18  <tjfontaine>right which is why it's a "leak" and not a Leak
23:13:27  <trevnorris>ah. got it. :)
23:13:52  <trevnorris>but still. it super complicates understanding how stuff works.
23:14:06  <trevnorris>and part of the reason for the Buffer changes to begin w/.
23:14:08  <tjfontaine>but anyway, this sort of mechanism which is being used for tls_wrap might be able to be reused into an http_wrap
23:14:24  <trevnorris>i like it.
23:14:30  * piscisaureus_joined
23:14:52  <tjfontaine>I'm still more in favor of a js http parser, but that won't happen before 1.0
23:16:02  <trevnorris>tjfontaine: shouldn't you declare "virtual ~StreamWrap" since you've declared other virtual methods?
23:17:47  <tjfontaine>there's no real state associated with the base class is there?
23:18:03  <trevnorris>i dunno. just repeating what i've read on SO. :)
23:18:14  <tjfontaine>anyway mine shouldn't be used for much more than an idea, as fedors was more fleshed out
23:18:29  <tjfontaine>there's not as much reuse as I'd like in his, but the concept is quite similar
23:19:52  <trevnorris>fwiw, created a hook so you can pass around the js object, extract it and add a callback after the fact: https://github.com/trevnorris/node/commit/56e5bbf
23:20:16  <trevnorris>super nasty right now, so please don't judge.
23:29:01  * loladiroquit (Quit: loladiro)
23:30:27  * loladirojoined
23:33:03  * loladiroquit (Client Quit)
23:39:12  * dominictarrquit (Quit: dominictarr)
23:47:13  * EhevuTov__joined
23:49:03  <trevnorris>ircretary: tell bnoordhuis fprintf'd &id_ usually has values like 0xfc8540, but just before seg fault has 0x10.
23:49:03  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
23:50:04  * EhevuTov_quit (Ping timeout: 246 seconds)
23:51:44  <trevnorris>ircretary: tell bnoordhuis and printed "this", right before crashing this == (nil).
23:51:45  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
23:52:06  * c4miloquit (Remote host closed the connection)
23:52:12  <trevnorris>tjfontaine: so seems the class is being destructed before that operation has a chance to run.
23:55:51  * EhevuTov__quit (Quit: This computer has gone to sleep)
23:58:12  * hzquit