[00:03:52] * csteipp shakes fist at 10yo home router [00:04:02] tgr: Sorry, I'm not trying to avoid it. But I'm also not sure if I'm in this enough to make the call which is better. I'm happy as long as any tokens which may have been stolen are invalid, and can't be reconstructed from public info. If that means keeping running the script, then we should do that. [00:04:06] I think my preference would be we finish resetting the tokens faster than 1000/hr [00:04:08] 10,000/hr that is :) [00:04:10] tgr: ^ [00:04:40] ack [02:00:00] tgr: I'm going mostly afk, but you have my trust on what to do when. [19:49:22] bd808: I thought hhvm.error_handling.call_user_handler_on_fatals gives you stack traces [19:49:48] isn't that the whole point of using it? [20:02:44] so if something ends up in fatal.log that means HHVM's user handler handled it, and if it ends up in hhvm.log that means the error handler was somehow removed and HHVM's normal fatal handling handled it, hence no stack trace? [20:03:07] it would be interesting to see if gzip breaks in both cases [21:47:13] tgr|away: setting call_user_handler_on_fatals=1 is supposed to call the currently installed handler and pass a 6th argument containing a stacktrace when the interpreter trips on a fatal error. I don't know if it always does so, or if our MWExceptionHandler::handleError handler is always installed when such things happen. I'd have to go back and read the code again to remember if things only end up in the hhvm log stream when the handler is [21:47:13] missing or not.