> Thanks for the feedback. If you have the time/inclination to describe
> (roughly) the sort of patch you'd like to see and the subtle problems,
> I'd be happy to revise my patch and try to help move things forward.

> Thanks,

> d.

> On Mon, Nov 5, 2012 at 4:37 AM, Yang Guo <yang...@chromium.org> wrote:
> > (previously sent without actually finishing the mail...)

> > Hi Dave,

> > I wasn't aware of this problem before. We currently already have
> redundant
> > ways to capture stack trace (at throw site and at creation site of the
> Error
> > object). I've been wanting to consolidate this, which would also enable
> me
> > to solve this issue.

> > Your current approach has some subtle problems. If you have some
> patience,
> > as I will be working on this issue, it will be solved eventually. I'll
> file
> > a bug for this.

> > Yang

> > On Mon, Nov 5, 2012 at 12:36 PM, Yang Guo <yang...@chromium.org> wrote:

> >> Hi Dave,

> >> I wasn't aware of this problem before. We currently already have
> redundant
> >> ways to capture stack trace (at throw site and at creation site of the
> Error
> >> object). I wanted to consolidate those

> >> On Sat, Nov 3, 2012 at 4:02 AM, Dave Smith <diz...@singly.com> wrote:

> >>> Hi,

> >>> I've been using node.js (and hence, v8) for a little bit and one thing
> >>> that has driven me nuts is the lack of reporting when the call stack
> >>> overflows. So, in keeping with open source tradition, I've knocked
> together
> >>> a (simplistic) patch to fix this specific problem. My patch is here:

> https://github.com/dizzyd/node/commit/40434019540ffc17e984ff0653500a3...

> >>> (note that it's against the fork of the node codebase, which embeds v8
> >>> directly).

> >>> My lack of familiarity with v8 is probably grossly evident, but perhaps
> >>> someone could provide some direction on improvements if this is an itch
> >>> bothering other people. :)

> >>> Thanks!

> >>> D.

> >>> --
> >>> v8-dev mailing list
> >>> v8-dev@googlegroups.com
> >>> http://groups.google.com/group/v8-dev