Open Bug 643666 Opened 10 years ago Updated 7 years ago

Capturing JS executions

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

People

(Reporter: bhackett1024, Unassigned)

Details

Resurrecting an idea from last year...

I find debugging JS issues in the shell to be pretty fun and easy.  The shell is deterministic: running a test over and over gives the same scripts, behavior, even (at least on OSX) the same pointer addresses, and it's quick to narrow down a bug's cause.

In my very limited experience, I also find debugging JS issues in the browser to be more painful and time consuming, primarily due to the browser's non-determinism.

It would be nice if debugging JS issues found using the browser was as easy as those found with shell tests.  Being able to replay the whole browser deterministically is some distance off, but I don't think it would be hard to isolate the places where JS interacts with the rest of the browser and record those interactions to disk.  Those interactions could then be replayed later in the shell, hopefully with any bugs or other interesting behavior still intact.  This would work better for some bugs (codegen, VM) than others (GC).

This still would be a little nasty due to having a large blob of data to run in the shell rather than a 2 line test.  For some categories of bugs (codegen) where we can get both good and bad behavior out of the shell (e.g. no flags vs. -m -n), we could binary-search the execution using state snapshots/hashes and counters down to where the behaviors diverge.

A secondary benefit would be to bottle up executions of JS-heavy webpages so that we could easily measure their behavior and watch our performance characteristics change over time, AWFY style.

Interest?
We have an intern lined up for this, as long an end-of-summer timeline works for you.
Cool, that should work.  Who is the intern?  Is there a bug?
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.