Yang, Dave has already uploaded the patch at https://codereview.chromium.org/13071005/. It would be great if you had time to take a look, I'm not sure when I'll get around to it myself.
On Wed, Mar 27, 2013 at 11:10 AM, Yang Guo <[email protected]> wrote: > Hi Dave, > > Not sure if this really needs adding a command line flag. Wouldn't it be > sufficient to set a break point in DoThrow when you need it? Or is it not > possible to attach gdb? In that case, please follow > https://code.google.com/p/v8/wiki/Contributing so that we can land the > patch for you. The patch by itself looks alright to me, but you might want > to consider adding OS::DumpBacktrace() as well. > > Yang > > > On Thursday, February 21, 2013 9:59:50 PM UTC+1, Dave Pacheco wrote: >> >> Last year I worked with members of the V8 team to add low-overhead debug >> information to V8 so that we could debug Node.js programs postmortem.[1] >> This >> information has proven quite valuable, and we've configured our Node >> programs to >> invoke abort(3C) (via Node's process.abort()) whenever we get the >> "uncaughtException" event. We've nailed several nasty production issues >> based >> on the resulting core files without having to reproduce the problem. See >> [2] >> for a particularly nasty example. >> >> That said, there's one problem with this approach: by the time we get to >> the >> uncaughtException handler, all of the stack state associated with the >> exception >> is gone. If we blow an assertion or trip over an undefined variable >> inside a >> function, it's often valuable to know what the arguments to that function >> were, >> but that's all gone by the time the event is emitted. My proposal is to >> add a >> command line flag that causes V8 to call OS::Abort when an uncaught >> exception is >> emitted. The diffs are pretty small: >> >> https://github.com/**davepacheco/v8/commit/** >> d917219c4c43511ecc05b0a466fa52**058d9cfe53<https://github.com/davepacheco/v8/commit/d917219c4c43511ecc05b0a466fa52058d9cfe53> >> >> but the result is that we get a core file with the current JavaScript >> stack >> intact, including arguments. This particular change helped us nail two >> instances of RangeError (see [3] for my write-up of one of them). >> >> If the team is okay with this change, I'd like to submit a code review >> and have >> it integrated into V8. >> >> Thanks, >> Dave >> >> [1] >> https://chromiumcodereview.**appspot.com/8803024<https://chromiumcodereview.appspot.com/8803024> >> [2] >> https://github.com/joyent/**node/issues/4785<https://github.com/joyent/node/issues/4785> >> [3] http://dtrace.org/blogs/dap/**2012/05/14/debugging-** >> rangeerror-from-a-core-dump/<http://dtrace.org/blogs/dap/2012/05/14/debugging-rangeerror-from-a-core-dump/> >> >> -- > -- > v8-users mailing list > [email protected] > http://groups.google.com/group/v8-users > --- > You received this message because you are subscribed to the Google Groups > "v8-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
