00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:05:12  * a_lequit (Remote host closed the connection)
00:07:54  * sblomquit (Read error: Connection reset by peer)
00:08:08  * thlorenzquit (Remote host closed the connection)
00:09:39  * iarnaquit (Remote host closed the connection)
00:13:08  * thlorenz_joined
00:16:10  * chris_99quit (Quit: Ex-Chat)
00:22:28  * thlorenz_quit (Remote host closed the connection)
00:23:56  * a_lejoined
00:33:10  * a_lequit (Remote host closed the connection)
00:34:00  * a_lejoined
00:34:03  * dap_quit (Quit: Leaving.)
00:34:12  * kriskowaljoined
00:35:38  * AlexisMochajoined
00:42:34  * stagasjoined
00:48:44  * dap_joined
00:51:43  * dshaw_quit (Quit: Leaving.)
00:55:14  * iarnajoined
00:58:03  * Fishrock123joined
01:05:38  * sblomjoined
01:08:32  * Fishrockjoined
01:08:39  * Fishrock123quit (Read error: Connection reset by peer)
01:10:50  * dap_quit (Quit: Leaving.)
01:20:18  * avalanche123quit (Remote host closed the connection)
01:34:05  * abraxas_joined
01:38:12  * thlorenzjoined
01:38:40  * kazuponjoined
01:39:15  * abraxas_quit (Ping timeout: 265 seconds)
01:45:53  * kriskowalquit (Quit: kriskowal)
01:48:24  * yournamejoined
01:48:43  * sblomquit (Read error: Connection reset by peer)
01:52:30  * ijrothquit (Quit: Leaving.)
02:07:42  * Ralithquit (Ping timeout: 265 seconds)
02:09:24  * dshaw_joined
02:12:32  * a_lequit (Ping timeout: 265 seconds)
02:23:00  * yournamequit (Quit: leaving)
02:26:01  * toothrotjoined
02:26:57  * abraxas_joined
02:30:45  * Fishrockquit (Quit: Leaving...)
02:31:35  * Ralithjoined
02:40:05  * AlexisMochaquit (Ping timeout: 265 seconds)
02:51:09  * a_lejoined
02:58:49  * WalrusPonyjoined
03:01:06  * WalrusPony1quit (Ping timeout: 255 seconds)
03:07:14  * iarnaquit (Remote host closed the connection)
03:10:22  * a_le_joined
03:10:32  * a_lequit (Ping timeout: 265 seconds)
03:13:49  * thlorenzquit (Remote host closed the connection)
03:14:42  * jgiquit (Quit: jgi)
03:16:39  * brsonquit (Quit: leaving)
03:17:20  * brsonjoined
03:31:19  * piscisaureusquit (Ping timeout: 265 seconds)
03:33:49  * dshaw_quit (Quit: Leaving.)
03:34:37  * brsonquit (Quit: leaving)
03:56:00  * dshaw_joined
04:03:54  * yunongquit (Read error: Network is unreachable)
04:04:29  * yunongjoined
04:05:55  * ferossquit (Ping timeout: 272 seconds)
04:05:56  * mikolalysenko_quit (Ping timeout: 272 seconds)
04:06:09  * rphillipsquit (Read error: Connection reset by peer)
04:06:10  * Raynosquit (Write error: Connection reset by peer)
04:06:29  * felixge_____joined
04:06:36  * rphillipsjoined
04:06:39  * ferossjoined
04:07:24  * mikolalysenko_joined
04:07:26  * groundwater__joined
04:09:14  * benoitc_joined
04:09:50  * isaacs_joined
04:10:04  * isaacsquit (Disconnected by services)
04:11:02  * kazuponquit (Remote host closed the connection)
04:11:39  * Raynosjoined
04:11:50  * Left_Turnquit (Remote host closed the connection)
04:12:01  * kkaefer_joined
04:12:05  * pquernaquit (Disconnected by services)
04:12:08  * pquerna_joined
04:12:25  * groundwater_quit (Ping timeout: 272 seconds)
04:12:25  * felixge____quit (Ping timeout: 272 seconds)
04:12:26  * zj99f_joined
04:12:27  * benoitcquit (Ping timeout: 272 seconds)
04:12:27  * rjequit (Ping timeout: 272 seconds)
04:12:27  * kkaeferquit (Ping timeout: 272 seconds)
04:12:28  * Wraithanquit (Ping timeout: 272 seconds)
04:12:28  * zj99fquit (Ping timeout: 272 seconds)
04:12:48  * groundwater__changed nick to groundwater_
04:13:21  * felixge_____changed nick to felixge____
04:13:28  * Wraithanjoined
04:14:22  * dshaw_quit (Quit: Leaving.)
04:14:31  * pquerna_changed nick to pquerna
04:14:54  * rjejoined
04:15:46  * benoitc_changed nick to benoitc
04:21:50  * bradleymeckjoined
04:22:19  * avalanche123joined
04:24:06  * stagasquit (Read error: Connection reset by peer)
04:26:34  * avalanche123quit (Ping timeout: 244 seconds)
04:29:46  * stagasjoined
04:46:22  * kazuponjoined
04:49:10  * stagasquit (Ping timeout: 258 seconds)
04:49:43  * abraxas_quit (Remote host closed the connection)
04:51:27  * abraxas_joined
05:03:34  * janjongboomjoined
05:10:03  * bradleymeckquit (Quit: bradleymeck)
05:26:16  * AvianFluquit (Ping timeout: 264 seconds)
05:29:08  * bradleymeckjoined
05:32:34  * seishunjoined
05:37:44  * toothrotquit (Ping timeout: 245 seconds)
05:49:39  * bradleymeckquit (Quit: bradleymeck)
05:50:17  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:21:17  * octetcloudquit (Ping timeout: 240 seconds)
06:25:10  * thlorenzjoined
06:29:36  * thlorenzquit (Ping timeout: 258 seconds)
06:44:18  * seishunquit (Ping timeout: 244 seconds)
06:44:36  * janjongboomjoined
06:47:11  * kazuponquit (Read error: Connection reset by peer)
06:47:14  * kazupon_joined
06:59:21  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
07:11:14  * janjongboomjoined
07:11:37  * a_le_quit (Remote host closed the connection)
07:12:18  * a_lejoined
07:13:21  * janjongboomquit (Client Quit)
07:41:52  * kazupon_quit (Remote host closed the connection)
07:45:59  * kazuponjoined
07:48:30  * Ldxngx_joined
07:48:34  * Ldxngx_quit (Client Quit)
07:48:43  * Ldxngx_joined
07:48:43  * Ldxngx_quit (Client Quit)
07:49:09  * Ldxngx_joined
07:49:23  * Ldxngx_quit (Client Quit)
07:49:32  * Ldxngx_joined
07:49:45  * Ldxngx_quit (Client Quit)
07:49:54  * Ldxngx_joined
07:56:09  * bajtosjoined
07:56:30  * Ldxngx_changed nick to Ldxngx
08:02:00  * Ldxngxquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
08:02:11  * Ldxngxjoined
08:02:57  * rendarjoined
08:32:59  * janjongboomjoined
08:37:03  * SergeiRNDjoined
08:40:59  * SergeiRND1joined
08:44:53  * SergeiRNDquit (Ping timeout: 264 seconds)
08:55:37  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:23:19  * bradleymeckjoined
09:23:45  * janjongboomjoined
09:31:10  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:38:23  * inolenquit (Quit: Leaving.)
09:49:51  * Left_Turnjoined
09:55:44  * stagasjoined
10:00:19  * janjongboomjoined
10:05:26  * ijrothjoined
10:08:10  * janjongboomquit (Read error: Connection reset by peer)
10:08:40  * janjongboomjoined
10:21:02  * janjongboomquit (Read error: Connection reset by peer)
10:21:57  * bajtospart
10:22:26  * bajtosjoined
10:27:09  * janjongboomjoined
10:32:16  * AlexisMochajoined
10:38:53  * janjongboomquit (Ping timeout: 240 seconds)
10:47:07  * janjongboomjoined
10:47:48  * SergeiRND1quit (Quit: Leaving.)
10:56:45  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
11:02:33  * kazuponquit (Remote host closed the connection)
11:04:32  * janjongboomjoined
11:14:44  * bajtosquit (Quit: bajtos)
11:20:58  * SergeiRNDjoined
11:25:38  * chris_99joined
11:25:39  * ijrothquit (Quit: Leaving.)
11:31:37  * abraxas_quit (Remote host closed the connection)
11:32:12  * abraxas_joined
11:36:37  * abraxas_quit (Ping timeout: 240 seconds)
11:50:53  * bajtosjoined
11:58:36  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:21:41  * iarnajoined
12:34:42  * janjongboomjoined
12:36:39  * bradleymeckquit (Quit: bradleymeck)
12:42:27  * iarnaquit (Remote host closed the connection)
12:44:25  * piscisaureusjoined
12:45:10  * iarnajoined
12:45:27  * bradleymeckjoined
12:53:58  * bradleymeckquit (Quit: bradleymeck)
13:09:12  * dshaw_joined
13:14:10  * bajtosquit (Quit: bajtos)
13:21:01  * abraxas_joined
13:25:17  * abraxas_quit (Ping timeout: 240 seconds)
13:31:35  * iarnaquit (Remote host closed the connection)
13:31:38  * AvianFlujoined
13:32:03  * iarnajoined
13:32:40  * bajtosjoined
13:37:11  * iarnaquit (Remote host closed the connection)
13:38:33  * euoiaquit (Ping timeout: 258 seconds)
13:43:53  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:44:51  * euoiajoined
13:49:41  * euoiaquit (Remote host closed the connection)
13:56:52  * euoiajoined
13:59:59  * stagasquit (Ping timeout: 272 seconds)
14:02:15  * SergeiRNDquit (Quit: Leaving.)
14:15:11  * euoiaquit (Ping timeout: 265 seconds)
14:16:32  * SergeiRNDjoined
14:18:04  * dsantiagoquit (Ping timeout: 250 seconds)
14:19:35  * SergeiRNDquit (Client Quit)
14:22:21  * SergeiRNDjoined
14:25:57  * dsantiagojoined
14:32:54  * euoiajoined
14:34:20  * dshaw_quit (Quit: Leaving.)
14:36:46  * SergeiRNDquit (Quit: Leaving.)
14:38:38  * Fishrock123joined
14:41:02  * euoiaquit (Ping timeout: 258 seconds)
14:41:17  * dshaw_joined
14:45:45  * kazuponjoined
14:52:52  <kellabyte>ok this is strange, I compiled and ran my code like a hundred times and it worked fine, I made no changes and now this assertion fires
14:52:57  <kellabyte>lib/libuv/src/unix/stream.c:547: uv_accept: Assertion `server->loop == client->loop' failed.
14:53:07  <kellabyte>any thoughts? :P
14:59:07  <kellabyte>looks like it's checking that the server and client event loops aren't the same? but odd that this only started failing now not all the time
15:02:36  * lance|afkchanged nick to lanceball
15:05:05  * dshaw_quit (Quit: Leaving.)
15:06:23  * a_lequit (Remote host closed the connection)
15:09:10  <txdv>kellabyte: what did you change?
15:09:58  * abraxas_joined
15:10:03  <txdv>2011-08-31 13:41 Ryan Dahl 6fd340b /* TODO document this */
15:10:04  <txdv>2011-08-31 13:41 Ryan Dahl 6fd340b assert(server->loop == client->loop);
15:10:10  <txdv>:D
15:10:17  <txdv>this shit has propagated for 3 years
15:10:18  <txdv>as a todo
15:10:24  <kellabyte>nothing lol, I recompiled my code with some config changes but I did that like 100 times yesterday, I put the changes back to normal and its still doing it
15:10:30  * dshaw_joined
15:11:03  <txdv>it is checking exactly the opposite
15:11:10  <txdv>the client and server loop have to be the same
15:11:31  <kellabyte>ah
15:11:49  <txdv>assert(0) will return a runtime error
15:11:53  <txdv>throw
15:11:54  <txdv>whatever
15:12:00  * bajtosquit (Quit: bajtos)
15:12:02  <txdv>assert(1) everything is fine!
15:12:08  <kellabyte>no idea how this can magically assert all the sudden lol
15:12:23  <txdv>do you have multiple threadS?
15:12:33  <txdv>Or only one thread with one loop?
15:14:38  * abraxas_quit (Ping timeout: 265 seconds)
15:21:35  <kellabyte>I'm creating multiple event loops and communicating over IPC
15:23:20  <txdv>so you are probably acceptign in a different event loop
15:23:27  <txdv>instead of accepting in the same one and then sending via IPC
15:26:10  * stagasjoined
15:26:13  <kellabyte>I guess but how was this working before with no code changes? lol
15:26:42  <txdv>it didn't
15:26:53  <txdv>maybe you compiled a release version of libuv
15:27:02  <txdv>which ignores asserts?
15:28:51  <kellabyte>naa, it was working in debug
15:29:14  <txdv>ok
15:29:27  <txdv>a miracle
15:29:31  <txdv>praise the lord
15:29:58  <kellabyte>lol
15:30:01  <kellabyte>something is up
15:35:14  * thlorenzjoined
15:35:55  <txdv>saghul might return from his holidays
15:36:03  <txdv>and release the request based read api
15:37:34  <kellabyte>what's request based read api?
15:37:42  <kellabyte>btw I just did a git clone fresh, and it runs fine
15:37:46  <kellabyte>lol something is wacky
15:40:48  * thlorenzquit (Remote host closed the connection)
15:49:48  * janjongboomjoined
15:53:54  * kriskowaljoined
15:57:33  * chris_99quit (Remote host closed the connection)
15:57:37  <kellabyte>ok I was able to reproduce the issue
15:57:37  <txdv>kellabyte: uv_read_start/stop will change to what write has
15:57:39  <kellabyte>wow this is so weird
15:57:45  <txdv>so
15:57:58  <txdv>you kiss your cat, turn 3 circles around the chair and then the bug appears?
15:58:16  * avalanche123joined
15:59:54  <kellabyte>ok lol so if I set haywire to create 8 event loops and communicate over IPC, everything runs fine
16:00:00  <kellabyte>if I set it to 256, this assert hits
16:00:09  <kellabyte>(recompile required in my code to make this change)
16:00:25  <kellabyte>if I then set it back to 8, and recompile, and re-run, the assert still happens
16:01:06  * avalanche123quit (Remote host closed the connection)
16:01:21  <kellabyte>this is the function I'm passing 8 or 256 to: https://github.com/kellabyte/Haywire/blob/master/src/haywire/http_server.c#L134
16:03:19  <kellabyte>and this is the line throwing the assert: https://github.com/kellabyte/Haywire/blob/master/src/haywire/connection_consumer.c#L29
16:03:46  <kellabyte>but why only when I set it to 256, and its like once it is broke, its now broke for 8, even though 8 just worked
16:04:04  <kellabyte>even though its separate process runs
16:04:10  <kellabyte>so confused :P
16:04:11  * avalanche123joined
16:16:37  * thlorenzjoined
16:25:58  * a_lejoined
16:29:28  * dshaw_quit (Quit: Leaving.)
16:34:53  * kazuponquit (Remote host closed the connection)
16:37:05  * avalanche123quit (Remote host closed the connection)
16:38:02  * iarnajoined
16:42:22  * inolenjoined
16:42:42  * iarnaquit (Ping timeout: 256 seconds)
16:43:42  * seishunjoined
16:47:05  * lanceballchanged nick to lance|afk
16:49:40  * bradleymeckjoined
16:54:43  * dshaw_joined
16:56:43  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:58:36  * abraxas_joined
17:00:19  * janjongboomjoined
17:03:39  * abraxas_quit (Ping timeout: 272 seconds)
17:10:32  * jgijoined
17:13:41  <trevnorris>tjfontaine: ping
17:17:18  * dap_joined
17:21:34  * piscisaureusquit (Ping timeout: 244 seconds)
17:25:17  * iarnajoined
17:26:01  * bajtosjoined
17:28:10  <trevnorris>jgi: ping
17:28:16  <jgi>trevnorris: pong
17:28:48  <trevnorris>jgi: not sure if you've seen https://github.com/joyent/node/pull/8110 in the last day, but i'm fixing up the commits.
17:28:53  <trevnorris>things are a lot different now.
17:29:02  <trevnorris>and still in process of getting everything in place.
17:30:24  <jgi>trevnorris: ok, I was planning to continue reviewing/getting a better understanding of it today, so I will let you know if I have any question, thank you very much for the heads up :)
17:31:31  <trevnorris>jgi: np. each commit should be pretty well self contained. i.e. a lot easier to understand in context.
17:32:13  * Ralithquit (Ping timeout: 255 seconds)
17:32:22  * isaacs_changed nick to isaacs
17:37:44  * iarnaquit (Remote host closed the connection)
17:38:35  * iarnajoined
17:41:09  * avalanche123joined
17:45:37  * brsonjoined
17:45:43  * kazuponjoined
17:47:30  * bajtosquit (Quit: bajtos)
17:49:14  * bajtosjoined
17:49:53  * kazuponquit (Ping timeout: 240 seconds)
17:57:46  * Ralithjoined
17:58:45  * AlexisMochaquit (Ping timeout: 272 seconds)
17:59:52  * AvianFluquit (Ping timeout: 245 seconds)
18:07:08  * iarnaquit (Ping timeout: 256 seconds)
18:07:28  * iarnajoined
18:07:46  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
18:17:18  * iarnaquit (Remote host closed the connection)
18:17:48  * kriskowalquit (Quit: kriskowal)
18:18:53  * iarnajoined
18:21:14  * iarnaquit (Remote host closed the connection)
18:25:45  * AvianFlujoined
18:28:21  * iarnajoined
18:33:55  * kriskowaljoined
18:34:43  * avalanche123quit (Remote host closed the connection)
18:36:25  * iarnaquit (Remote host closed the connection)
18:40:13  * iarnajoined
18:41:01  * AlexisMochajoined
18:41:13  * avalanche123joined
18:41:41  * iarnaquit (Remote host closed the connection)
18:43:16  * thlorenzquit (Remote host closed the connection)
18:45:42  * lance|afkchanged nick to lanceball
18:47:36  * abraxas_joined
18:51:56  * abraxas_quit (Ping timeout: 250 seconds)
18:55:10  * iarnajoined
18:55:16  * nathan7quit (Remote host closed the connection)
18:58:58  <jgi>trevnorris: When do you think you’ll be done getting everything in place? In other words, when would be a good time to run tests on all platforms?
18:59:29  * thlorenz_joined
19:07:06  <trevnorris>jgi: honestly? I've given up on giving a time. Thought I'd be done last week, up until I realized Node manually deconstructs the classes attached to JS objects, causing segfaults when trying to access native properties on those objects.
19:08:06  <trevnorris>so, basically, i'm implementing a subset of things that work and going to call it good at that. we can work on implementing the rest after the v0.12 release since it's all internal API anway.
19:08:16  <jgi>trevnorris: ok
19:08:32  <trevnorris>jgi: i'll give you an update by EOD with how far I am.
19:08:39  <jgi>trevnorris: cool great!
19:08:54  <jgi>trevnorris: also, just for my own curiosity, what do you mean by “Node manually deconstructs the classes attached to JS objects”?
19:09:16  * nathan7joined
19:09:59  * iarnaquit (Remote host closed the connection)
19:11:09  <trevnorris>jgi: internally we construct an object and attach the pointer to a constructed class. though the class is delete'd manually instead of allowing GC to clean it up.
19:11:19  <trevnorris>thus the pointer to the class attached to the JS object is then invalid.
19:11:30  * iarnajoined
19:13:06  <jgi>trevnorris: where is the class deleted manually?
19:13:49  <trevnorris>everywhere. e.g. FSReqWrap in the After callback.
19:14:04  <trevnorris>i.e. when the req_wrap has completed it's purpose (req is complete)
19:14:27  * inolenquit (Quit: Leaving.)
19:17:08  * Fishrockjoined
19:21:03  * iarnaquit (Remote host closed the connection)
19:21:30  * iarnajoined
19:21:44  * Fishrock123quit (Ping timeout: 272 seconds)
19:22:16  * kriskowalquit (Quit: kriskowal)
19:27:21  * kriskowaljoined
19:27:28  <MI6>joyent/node: Steven Loomis v0.12 * 855b1c9 : build: i18n: support little-endian machines - http://git.io/XbkKkA
19:28:04  * iarnaquit (Ping timeout: 264 seconds)
19:28:26  * bradleymeckquit (Quit: bradleymeck)
19:28:39  * octetcloudjoined
19:31:54  * jgiquit (Quit: jgi)
19:31:59  * iarnajoined
19:34:25  * avalanche123quit (Remote host closed the connection)
19:36:31  * jgijoined
19:42:35  * avalanche123joined
19:45:16  * bajtosquit (Quit: bajtos)
19:53:27  * a_lequit (Ping timeout: 265 seconds)
19:59:15  * Ldxngxquit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
20:04:26  * iarnaquit (Ping timeout: 256 seconds)
20:06:08  * rendarquit (Ping timeout: 256 seconds)
20:06:20  * iarnajoined
20:07:11  * kriskowalquit (Quit: kriskowal)
20:09:39  * iarnaquit (Remote host closed the connection)
20:12:01  * rendarjoined
20:18:33  * avalanche123quit (Remote host closed the connection)
20:20:40  * iarnajoined
20:21:05  * avalanche123joined
20:22:31  * inolenjoined
20:31:19  * thlorenz_quit (Remote host closed the connection)
20:32:07  * thlorenzjoined
20:36:17  * abraxas_joined
20:36:51  * ijrothjoined
20:40:01  * kenperkinsquit (Quit: Computer has gone to sleep.)
20:40:42  * avalanche123quit (Remote host closed the connection)
20:40:52  * lanceballchanged nick to lance|afk
20:41:17  * abraxas_quit (Ping timeout: 264 seconds)
20:42:13  * jgiquit (Quit: jgi)
20:44:06  * iarnaquit (Ping timeout: 256 seconds)
20:45:13  * dshaw_quit (Quit: Leaving.)
20:48:59  * dshaw_joined
20:50:50  * avalanch_joined
20:51:06  * avalanch_quit (Remote host closed the connection)
20:51:13  * avalanch_joined
20:51:51  * kriskowaljoined
20:53:02  <chrisdickinson>trevnorris: tjfontaine: dap_: is https://github.com/joyent/node/pull/8666 ready to go into v0.10?
21:02:06  * dshaw_quit (Quit: Leaving.)
21:02:39  * a_lejoined
21:07:06  * ijrothquit (Quit: Leaving.)
21:12:03  * iarnajoined
21:12:54  * janjongboomjoined
21:18:37  <trevnorris>chrisdickinson: how's this going to affect v0.12? i.e. will we have to float a similar patch?
21:19:10  <chrisdickinson>I asked a similar question :)
21:20:53  * iarnaquit (Remote host closed the connection)
21:21:40  <trevnorris>chrisdickinson: What would be the difference between SetFatalErrorHandler() and SetUncaughtExceptionHandler() ?
21:22:28  * jgijoined
21:22:30  * iarnajoined
21:22:53  <chrisdickinson>oh, I wasn't aware of FatalErrorHandler.
21:23:12  <trevnorris>yeah. we already use it, but it still doesn't catch errors thrown from a Promise.
21:23:48  <trevnorris>so i'd first bring up on the mailing list how to capture uncaught/fatal errors thrown from a Promise on the v8 mailing list.
21:26:40  * lance|afkchanged nick to lanceball
21:26:55  <chrisdickinson>from my understanding of promises, uncaught/fatal errors in promises linger forever without affecting the process
21:27:28  <trevnorris>yeah. and I doubt V8 will change that. So there'll be no way to catch an exception from a Promise that's been created within a domain.
21:28:17  <trevnorris>Domenic: since Promises don't allow exceptions to propagate, that implies there'll be no way for a tool like domain to catch it, right?
21:30:40  <chrisdickinson>forgive my naïvety, but is that an issue? promises don't seem to be able to "leak" exceptions out into their surroundings -- and it seems like the expectations are that something like domains wouldn't ever see those exceptions (since they're not being thrown all the way up the stack)
21:31:24  <chrisdickinson>to me it seems like promises and domains are in two separate worlds when it comes to error handling (for better or worse)
21:32:48  <trevnorris>Domenic will have to verify, but AFAIK Promises were implemented that way on purpose. It's an excellent way to completely ignore exceptions from your code!
21:33:05  * a_lequit (Ping timeout: 265 seconds)
21:33:33  <chrisdickinson>if it's the case that promises swallow exceptions (and domains can do nothing about them), does SetFatalErrorHandler address our needs in v0.12?
21:34:19  <chrisdickinson>(& if it does, what are the costs of floating a patch against v8 just for the v0.10 line? are we planning on upgrading v8 in v0.10 in the future?)
21:35:11  * a_lejoined
21:36:03  <trevnorris>chrisdickinson: V8::SetFatalErrorHandler() exists in v0.10.
21:36:11  <chrisdickinson>oh.
21:36:40  <trevnorris>it is the reason process._fatalException() gets called.
21:37:06  <trevnorris>simply checking a runtime flag and aborting() the moment SetFatalErrorHandle() would be enough.
21:39:11  <trevnorris>chrisdickinson: it might also be good if we fprintf(stderr) information about the failure, a lot like what V8 does in a Debug build.
21:39:21  <trevnorris>i.e. print out the stack trace, etc.
21:39:56  * kriskowalquit (Quit: kriskowal)
21:43:43  <jgi>trevnorris: do you mean that for v0.10 process_fatalException() is called by the handler passed to SetFatalErrorHandler?
21:43:53  <trevnorris>jgi: yes
21:44:47  <jgi>trevnorris: that was not my understanding, I thought that the handler passed to SetFatalErrorHandler was just aborting and that process._fatalException was called at different places when a TryCatch had caught.
21:45:37  <trevnorris>jgi: well, yeah. it only fires if an exception propagates.
21:46:24  <trevnorris>but from the name of the added function "SetShouldAbortOnUncaughtExceptionHandler" I assumed that's what was wanted.
21:46:46  <trevnorris>that name implies that the exception propagated.
21:47:32  <trevnorris>if that's the case then it would be easy enough to simply ReportException(); exit(); here: https://github.com/joyent/node/blob/v0.10/src/node.cc#L1922-L1924
21:47:57  <trevnorris>if the flag was set by passing --abort-on-uncaught-exception
21:48:23  <trevnorris>(which also implies Node should only abort if the exception was allowed to propagate)
21:49:27  * a_lequit (Ping timeout: 265 seconds)
21:50:11  * a_lejoined
21:55:48  <jgi>trevnorris: I’m not sure I understand what you mean, I was just saying that to me, SetFatalErrorHandler is unrelated to process._fatalException, at least in v0.10 (I haven’t checked in v0.12)
21:56:02  <jgi>trevnorris: it’s two completely unrelated things
21:56:33  <trevnorris>jgi: nope, same thing: https://github.com/joyent/node/blob/v0.10/src/node.cc#L1925-L1945
21:57:02  <chrisdickinson>trevnorris: i might be missing how to get from Isolate::DoThrow to node::OnFatalError
21:58:07  <jgi>trevnorris: but I thought that the “FatalErrorHandler” set by SetFatalErrorHandler was node::OnFatalError: https://github.com/joyent/node/blob/v0.10/src/node.cc#L2957
21:58:11  <jgi>trevnorris: am I missing something?
21:58:27  <trevnorris>derp... wrong code block. sec.
21:59:06  * iarnaquit (Read error: Connection reset by peer)
21:59:43  * iarnajoined
21:59:53  <trevnorris>jgi: the only way _fatalException runs is through node::FatalException().
22:00:14  <jgi>trevnorris: yes, I agree with you on that
22:02:05  * Fishrockquit (Remote host closed the connection)
22:02:25  <trevnorris>jgi: ah yes, I was mistaken. We have it setup so FatalException() is manually run in case of an exception. Because SetFatalErrorHandler() doesn't give the callback enough information to be very useful.
22:02:27  * iarnaquit (Read error: Connection reset by peer)
22:02:52  <trevnorris>though that should still imply that it's unnecessary to add anything to V8.
22:02:56  * iarnajoined
22:04:32  <jgi>trevnorris: my understanding was that the fatal error handler was used when v8 can’t continue its execution, which is different than when an error is thrown and the exception is uncaught
22:05:14  <trevnorris>jgi: can you give an example?
22:06:08  <chrisdickinson>seems like https://github.com/joyent/node/blob/v0.10/deps/v8/src/api.cc#L136-L142 is the only place that can *get* the handler,
22:06:35  <chrisdickinson>and https://github.com/joyent/node/blob/v0.10/deps/v8/src/api.cc#L247, https://github.com/joyent/node/blob/v0.10/deps/v8/src/api.cc#L240, and https://github.com/joyent/node/blob/v0.10/deps/v8/src/api.cc#L152 are the only cases where it's accessed
22:07:24  * iarnaquit (Ping timeout: 256 seconds)
22:07:55  <chrisdickinson>(which the most likely one to be used elsewhere seemed to me to be ReportApiFailure, which is used in bootstrapper.cc and handles.cc, in neither case related to uncaught exceptions)
22:08:02  <trevnorris>sorry, seems I've managed to diverge the conversation. if I understand correctly, the desire is that --abort-on-uncaught-exception will always abort if an exception is allowed to propagate, correct?
22:08:17  * a_lequit (Ping timeout: 272 seconds)
22:08:56  <chrisdickinson>if it is uncaught and allowed to propagate, yes
22:09:49  <jgi>trevnorris: an example could be a node program with a listener on process’ uncaughtException and an error is thrown and not caught, versus v8 is dead: https://github.com/joyent/node/blob/v0.10/deps/v8/src/api.cc#L240-L244
22:10:03  <trevnorris>okay, so why isn't it enough to add a runtime flag that's immediately checked in node::FatalException() and if true immediately runs ReportException() and exit's?
22:10:47  <jgi>trevnorris: to let domain handle the uncaught exception if there’s an active domain?
22:11:04  <trevnorris>and to run uncaughtException events.
22:11:13  <trevnorris>s/events/callbacks
22:12:30  <jgi>although uncaughtException listeners wouldn’t run if —abort-on-uncaught-exception is passed to node
22:12:51  <trevnorris>i'm confused again. isn't that the point?
22:12:54  <jgi>so if we didn’t want domains to be able to handle the error, then your suggestion would probably work
22:13:50  * lanceballchanged nick to lance|afk
22:14:05  <trevnorris>add a check in FatalException to see if there's an active domain.
22:14:10  <trevnorris>then allow to propagate.
22:14:12  <jgi>trevnorris: the point of having another handler for uncaught exception in v8 was to let domains handle uncaught exception, even if —abort-on-uncaught-exception is passed to node
22:14:19  * kenperkinsjoined
22:14:24  * kenperkinsquit (Remote host closed the connection)
22:14:26  <trevnorris>you don't need it.
22:15:02  <trevnorris>I don't have the time to hack it together right now, but it is absolutely not necessary to add anything to v8.
22:15:08  * seishunquit (Ping timeout: 265 seconds)
22:15:38  <chrisdickinson>followup: by aborting at the FatalException point, we've lost stack information (vs. aborting at DoThrow), yes?
22:15:40  <trevnorris>have the first check in FatalException be if (<abort on uncaught exception flag> && !<active domain>)
22:15:47  <trevnorris>in that case then immediately abort.
22:15:55  * kriskowaljoined
22:16:00  <trevnorris>you'll also have to make a slight change in https://github.com/joyent/node/blob/v0.10/src/node.js#L264-L267
22:16:00  <jgi>chrisdickinson: yes, that’s what I’m trying to make sure of right now :)
22:16:03  * kenperkinsjoined
22:16:33  <trevnorris>to check the flag and return immediately if that's the case. bypassing any uncaughtException event callbacks.
22:21:02  * Fishrock123joined
22:22:21  <jgi>trevnorris: also, the reason why we have this handler in v8 is that I didn’t want to hardcode the test for —abort-on-uncaught-exception in node
22:22:49  <trevnorris>it's far better to add a runtime check to code we control then to float a patch on a dep we don't control.
22:22:50  <jgi>trevnorris: since it’s something specific to v8, that imho should not known by node
22:22:56  <trevnorris>it's also a solution we can port to v0.12.
22:23:59  <trevnorris>from C++ we're wrapping all JS calls in a TryCatch, which means technically nothing propagates. We have to manually do that ourselves.
22:24:16  <trevnorris>and we do this so we have additional information about the exception (i.e. the stack trace)
22:24:48  <trevnorris>whereas with SetFatalErrorHandle() we loose all that information.
22:30:30  <chrisdickinson>as I understand it, SetFatalErrorHandler doesn't handle uncaught exceptions -- or, at least, I'm not seeing the connection between it and Isolate::DoThrow
22:30:54  <jgi>chrisdickinson: right
22:31:13  <jgi>trevnorris: by aborting in FatalException, as chrisdickinson said, wouldn’t we loose all the information about the JS frames where the exception was thrown?
22:31:52  <trevnorris>jgi: a TryCatch instance is passed to FatalException with all the information about the exception.
22:31:55  <chrisdickinson>it looks like DoThrow ignores all C++-level TryCatches, so the original behavior of abort-on-uncaught-exception was to ignore FatalException
22:32:15  <trevnorris>hence why we manually call it on on try_catch.HasCaught()
22:32:18  <chrisdickinson>trevnorris: but the core dump will not contain the stack frames -- those'll be in an object
22:32:38  <jgi>trevnorris: right, but —abort-on-uncaught-exception is useful if we can generate a core and get the full stack trace from where the error was thrown, can we generate such a core with the info passed to FatalException?
22:33:04  <trevnorris>you can print the full stack trace from the try_catch, and running abort() will dump the core.
22:34:11  <trevnorris>V8 does this in a debug build. it first prints a ton of info about what happened then give you the core file for further analysis.
22:34:43  <trevnorris>chrisdickinson: what is this Isolate::DoThrow()?
22:35:25  <chrisdickinson>Isolate::DoThrow is what gets called when an exception is thrown in JS, if I understand this correctly
22:35:27  <chrisdickinson>https://github.com/joyent/node/blob/v0.10/deps/v8/src/isolate.cc#L1085
22:35:49  <chrisdickinson>originally it's where OS::Abort() would get called from if the flag was set
22:35:53  <chrisdickinson>https://github.com/joyent/node/blob/v0.10/deps/v8/src/isolate.cc#L1159-L1167
22:36:04  <trevnorris>okay, so you're talking V8 internal API.
22:36:23  <jgi>trevnorris: so when does v8 does that for debug builds? when there’s an uncaught exception?
22:36:49  <chrisdickinson>if the flag was set, it would ignore "external" handlers
22:36:58  <trevnorris>jgi: no, for more dire circumstances. e.g. improper use of the native API.
22:37:37  <chrisdickinson>(I'm basing this on the comment above the linked `if` statement -- "abort on any exception not caught by JavaScript, even when an external handler is present")
22:37:39  <trevnorris>but doesn't mean we can't print out the same type of information whenever we want.
22:38:11  <jgi>trevnorris: is it the default fatal error handler?
22:38:33  <trevnorris>for V8?
22:38:50  <jgi>trevnorris: yes, the abort + print message behavior for v8 debug builds
22:38:52  * avalanch_quit (Remote host closed the connection)
22:39:03  <trevnorris>let me generate one for you. sec.
22:40:05  <jgi>chrisdickinson: yes, that’s exactly what’s happening, and “external” handlers are C++ handlers
22:40:18  <chrisdickinson>cool, thanks for the confirmation
22:41:43  <jgi>chrisdickinson: so if there’s only “external” handlers, it means there’s no try/catch block to catch the exception, only a TryCatch instance up the stack in the C++ code that calls the JS code
22:43:26  <trevnorris>jgi: here's an example output from V8: https://gist.github.com/trevnorris/be1dee9d3fb4bc467b1c
22:43:38  <trevnorris>remember though, that's only for bad use of the native API.
22:43:47  <trevnorris>but it doesn't mean we can't do the same for any uncaught exception.
22:44:15  <trevnorris>iirc ben even wrote code to walk the stack and print both the JS and C++.
22:44:26  <jgi>trevnorris: right, but when they generate the core file, the frame where the error happened is still at the top of the stack right? I think that’s something we really want to keep with --abort-on-uncaught-exception
22:44:27  * kenperkins_joined
22:45:53  <chrisdickinson>if the JS frames (via ::DoThrow) are included in the core, you can get that information from {ll,m}db, & also print out / inspect function arguments, etc
22:46:08  * importantshockquit (Remote host closed the connection)
22:46:54  <chrisdickinson>jgi: am i understanding correctly that, prior to break-on-uncaught leaving v8, in break-on-uncaught mode fatalexception would never be called and a core would always be dumped?
22:47:09  <trevnorris>jgi: the top frame is the failed check. it's not until frame 3 or 4 that you reach the user's code.
22:47:48  <trevnorris>chrisdickinson: you can't get js frames from a core file. it has to be while the application is running.
22:47:52  * kenperkinsquit (Ping timeout: 258 seconds)
22:48:16  <trevnorris>and node has to be configured with --gdb, and you have to run node with --gdbjit --gdbjit-full
22:48:33  <jgi>chrisdickinson: what do you mean by “ break-on-uncaught leaving v8”?
22:48:34  <trevnorris>and gdb currently has a bug that causes a corrupt stack trace when it reaches JS
22:48:52  <trevnorris>and lldb 3.5+ currently doesn't work on linux.
22:48:56  <jgi>chrisdickinson: but yes to “in break-on-uncaught mode fatalexception would never be called and a core would always be dumped” :)
22:49:10  <chrisdickinson>err, http://neversaw.us/scratch/yakback/
22:49:37  <chrisdickinson>you can get the JS frames from a core that was generated with abort-on-uncaught-exception
22:49:45  <trevnorris>not on linux :P
22:49:50  <chrisdickinson>on linux, too
22:50:09  <chrisdickinson>you have to take the core and put both the core and the executable on a smartos box,
22:50:11  <chrisdickinson>but it can be done
22:50:19  <chrisdickinson>and there's work done towards getting it working with lldb, as well
22:50:23  * xer0xjoined
22:50:27  <trevnorris>seriously? when I say on linux, I mean all steps on linux.
22:50:53  <trevnorris>it did work on lldb on linux, but there's currently a bug that doesn't correctly recognize 64 bit applications.
22:51:42  <chrisdickinson>ah, i'm not sure about that. at the very least, you can generate cores from linux and debug them using mdb on smartos
22:52:14  <trevnorris>I have done the entire thing on Linux, but since then lldb introduced a bug. hopefully they'll get it fixed soon.
22:52:28  * thlorenzquit (Remote host closed the connection)
22:52:31  <chrisdickinson>I was checking the lldb version with https://github.com/tjfontaine/lldb-v8
22:52:43  <trevnorris>what version does it use?
22:52:45  <chrisdickinson>it's been ~1-2 months since I've rechecked using that approach
22:52:59  <chrisdickinson>unsure
22:53:01  <trevnorris>gdbjit only works w/ lldb on linux on 3.6-pre
22:53:35  <chrisdickinson>jgi: err, the "leaving v8" bit was a really poorly worded way of saying "the flag was removed from v8"
22:54:17  <chrisdickinson>jgi: and your proposed patch doesn't exactly restore the status quo so much as it improves it -- only aborting if the final domain throws?
22:55:14  <jgi>chrisdickinson: yes, the proposed patch basically allows domains to work if —abort-on-uncaught-exception is passed to node
22:55:28  <jgi>chrisdickinson: if the top level domain throws, node will abort and dump core
22:55:32  <trevnorris>chrisdickinson: that can be done by returning immediately from https://github.com/joyent/node/blob/v0.10/src/node.js#L264-L268
22:55:45  <trevnorris>that will bypass any uncaughtException callbacks
22:56:39  <chrisdickinson>i'm not sure if it would be salient at that point, but you'd still be missing js frames in the core (though they'd always be the same frames, if i'm not mistaken)
22:56:52  * thlorenz_joined
22:56:59  <trevnorris>what frames would you be missing?
22:57:07  <trevnorris>it will have unrolled the frames from the domain call (if there was one)
22:57:21  <trevnorris>but other than that it'll have everything about the callsite that threw.
22:57:41  * thlorenz_quit (Remote host closed the connection)
22:58:50  * thlorenzjoined
22:59:26  * thlorenzquit (Remote host closed the connection)
23:00:05  <chrisdickinson>hm,
23:00:18  <chrisdickinson>i suppose if you're using domains, getting a useful ::jsstack goes right out the window anyway
23:01:00  <trevnorris>yup.
23:01:05  <trevnorris>one of the many reasons I hate domains.
23:01:15  <trevnorris>hopefully the work on AsyncWrap that i'm wrapping up will greatly help w/ that..
23:02:02  * thlorenz_joined
23:02:02  <chrisdickinson>so putting an abort here https://github.com/joyent/node/blob/v0.10/src/node.cc#L1925-L1945 if caught is false and abort-on-uncaught is true handles the domains+abort-on-uncaught case
23:02:35  <chrisdickinson>but if you aren't using domains, putting an abort there instead of in DoThrow causes the core to omit valuable JS stack info, yes?
23:03:20  <trevnorris>chrisdickinson: before the abort() you'll want to ReportException()
23:03:32  * thlorenz_quit (Remote host closed the connection)
23:03:48  <trevnorris>no, it should work. here, let me hack together a patch.
23:04:06  * thlorenzjoined
23:04:15  <chrisdickinson>ReportException will output to stderr, yes?
23:05:04  <trevnorris>yes. but you have nothing to print.
23:05:25  <trevnorris>and unless you are on smartos, there's no way to see the stack trace from the core file.
23:05:33  <chrisdickinson>smartos or osx
23:05:44  <chrisdickinson>or can get the core to one of those boxes
23:05:48  <jgi>if I remember correctly, there’s also this call: https://github.com/joyent/node/blob/v0.10/lib/domain.js#L183 where, within a domain, if something is thrown, then passing —abort-on-uncaught-exception would always make node abort and dump core
23:06:19  <jgi>so I guess maybe it could be put within a try/catch block and call _fatalException if it throws
23:06:30  <jgi>but I haven’t thought too much about it, so it may be a bad idea
23:07:32  <jgi>with the patch I proposed, this is handled correctly (i.e, it doesn’t abort and dump core when —abort-on-uncaught-exception is passed to node) because the ShouldAbortOnUncaughtExceptionHandler determines there’s an active domain, and thus it doesn’t abort
23:08:36  * thlorenzquit (Ping timeout: 256 seconds)
23:15:08  * ijrothjoined
23:15:31  * ijrothquit (Client Quit)
23:16:31  * rendarquit
23:21:07  * kenperkinsjoined
23:22:46  * kenperkins_quit (Ping timeout: 255 seconds)
23:24:52  * robertkowalskiquit (Ping timeout: 245 seconds)
23:26:33  * Fishrock123quit (Remote host closed the connection)
23:27:00  * robertkowalskijoined
23:32:19  * trevnorrisquit (Quit: quit all you want)
23:33:24  <cjihrig>i've seen a number of node issues come through lately related to strict mode. are these likely v8 issues?
23:33:31  * trevnorrisjoined
23:34:16  * kenperkins_joined
23:34:23  * trevnorrisquit (Client Quit)
23:34:23  * robertkowalskiquit (Ping timeout: 244 seconds)
23:34:45  * trevnorrisjoined
23:36:13  * robertkowalskijoined
23:37:05  * kenperkinsquit (Ping timeout: 264 seconds)
23:37:42  * AvianFluquit (Ping timeout: 244 seconds)
23:39:25  * avalanche123joined
23:40:51  * chris_99joined
23:42:34  <jgi>trevnorris: When you come up with a better solution, could you please update https://github.com/joyent/node/pull/8666 so that everyone can participate and have up to date info?
23:43:53  * avalanche123quit (Ping timeout: 240 seconds)
23:43:54  * robertko1alskijoined
23:44:04  <trevnorris>jgi: sure
23:44:16  * robertkowalskiquit (Remote host closed the connection)
23:47:40  * trevnorrisquit (Quit: quit all you want)
23:48:00  * trevnorrisjoined
23:48:29  <chrisdickinson>where did we end up?
23:49:38  * robertko1alskiquit (Ping timeout: 250 seconds)
23:50:30  * robertkowalskijoined
23:51:08  * trevnorrisquit (Client Quit)
23:51:28  * trevnorrisjoined
23:52:02  <trevnorris>chrisdickinson: w/ the abort thing?
23:52:10  <chrisdickinson>yeah
23:52:58  <trevnorris>it's not necessary to add anything to V8. I'm still 100% focused on the AL patch, but once that's complete then I'll hack together a patch for that.
23:54:18  <chrisdickinson>I'm going to update the issue with a summary; this is pretty high priority for us since it affects our ability to debug.
23:55:46  * piscisaureusjoined
23:56:37  * toothrotjoined
23:56:48  * iarnajoined
23:57:15  <jgi>chrisdickinson, trevnorris: thanks