1479909 - Bit Bucket cannot be loaded

Status: RESOLVED FIXED

(Core Graveyard :: Web Replay, defect)

Description

[Jason Laster [:jlast]]

It looks like https://bitbucket.org/ crashes when webreplay is on.

CC https://twitter.com/niborst/status/1022704576078565376

Comment 1

[Brian Hackett [Laid off!]]

Hi, sorry for the late reply, I just started watching the Web Replay component (oops).  I'm not able to reproduce this, but there have been a fair number of fixes going in the last couple weeks which may have taken care of this.  Crash reporting should be working in today's Nightly (maybe tomorrow's) so if the issue still reproduces we should be able to figure out what the problem is from the report.

Comment 2

[Jason Laster [:jlast]]

Hmm, it still crashes for me. There should now be a crash report :wink:

Comment 3

[Brian Hackett [Laid off!]]

Attachment: patch

OK, I'm able to reproduce the crashes now.  This patch has a few small changes that get bitbucket.org to reliably record and rewind for me.

Comment 4

[Brian Hackett [Laid off!]]

Attachment: Part 1 - Tolerate multiple scripts with the same source when replaying.

The debugger in the recording/replaying process can see multiple onNewScript notifications for scripts with the same script source on this site.  This fix lets the debugger handle these correctly.  While this wasn't leading to crashes it did break the debugger.

Comment 5

[Brian Hackett [Laid off!]]

Attachment: Part 2 - Give replaying processes more time to execute before treating them as hanged.

Give replaying processes a lot more time to execute between checkpoints before treating them as hanged.  We had this low 5 second limit so that we could restart hanged processes without as much of an impact on the user, but this has turned out to be a lot more trouble than it's worth.  Giving 30 seconds to the replaying process should restrict crashes to actual hangs.

Comment 6

[Brian Hackett [Laid off!]]

Attachment: Part 3 - Disable DOM Ion optimizations when recording or replaying.

Ion optimizations of DOM accesses can observably affect the recording.  I think this is because operations which operate on wrapper caches (which interact with the recording, so accesses on their weakly held contents replay reliably) can be combined via GVN or LICM.  This patch disables all DOM optimizations when recording or replaying.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 9005487 [details] [diff] [review]
Part 3 - Disable DOM Ion optimizations when recording or replaying.

r=me

Comment 8

[Jim Blandy :jimb]

Comment on attachment 9005483 [details] [diff] [review]
Part 1 - Tolerate multiple scripts with the same source when replaying.

Review of attachment 9005483 [details] [diff] [review]:
-----------------------------------------------------------------

When I'm reading code and I see an `if` that I don't understand, it suggests to me that there are cases the code is dealing with that I'm not aware of. It'd be nice to have a brief comment explaining the conditions under which this can occur.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0e0a9ee8560a
Part 1 - Tolerate multiple scripts with the same source when replaying, r=jimb.
https://hg.mozilla.org/integration/mozilla-inbound/rev/45649765f2a9
Part 2 - Give replaying processes more time to execute before treating them as hanged, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/354e37362d06
Part 3 - Disable DOM Ion optimizations when recording or replaying, r=bz.

Comment 10

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/0e0a9ee8560a
https://hg.mozilla.org/mozilla-central/rev/45649765f2a9
https://hg.mozilla.org/mozilla-central/rev/354e37362d06