Skip to content

Conversation

@mhart
Copy link
Contributor

@mhart mhart commented Oct 20, 2025

Fixes #5332

I've confirmed this keeps the stack for any uncaught errors during startup:

service main: Uncaught Error: wtf
  at worker.js:14:11 in recurse2
  at worker.js:9:3 in recurse1
  at worker.js:16:3 in recurse2
  at worker.js:9:3 in recurse1
  at worker.js:16:3 in recurse2
  at worker.js:9:3 in recurse1
  at worker.js:16:3 in recurse2
  at worker.js:9:3 in recurse1
  at worker.js:16:3 in recurse2
  at worker.js:9:3 in recurse1

Turning this off any earlier (eg at the end of the Script constructor) is too early:

service main: Uncaught Error: wtf
  at worker.js:14:10

I've also confirmed this improves performance of running scripts with throw patterns as per #5332

@mhart mhart requested review from a team as code owners October 20, 2025 11:40
@mhart mhart changed the title Reset uncaught exception handling after Script construction Reset uncaught exception handling after startup execution Oct 20, 2025

// Reset this back to its default after startup execution
// Leaving it on comes at the expense of collecting stack traces for all thrown exceptions
if (script->isolate->impl->inspector == kj::none) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we set it to false regardless of inspector? Since we use inspector for profiling as well?

Copy link
Member

@kentonv kentonv Oct 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

EDIT: Ignore comment, I misread the condition.

In the Script constructor, we do:

      if (isolate->impl->inspector != kj::none || errorReporter != kj::none) {
        lock.v8Isolate->SetCaptureStackTraceForUncaughtExceptions(true);
      }

So if the inspector is off, but errorReporter is used (which is always the case in workerd, and in dynamic isolates), then the code as currently written will leave SetCaptureStackTraceForUncaughtExceptions() on.

I think that's not what we want? Seems like we should just turn it off unconditionally here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I misread the conditional.

OK, I could go either way on this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll check what the behaviour's actually like in the inspector after this change (we'd still want some way of getting unhandled exceptions with the inspector on if the user wants to – just not sure if there's a way to manually turn it on via Protocol Monitor or similar)

});

// Reset this back to its default after startup execution
// Leaving it on comes at the expense of collecting stack traces for all thrown exceptions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind adding a link to the github issue, so we don't lose the context?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, good idea 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make SetCaptureStackTraceForUncaughtExceptions configurable for a 26% speed boost

3 participants