Closed Bug 1194923 Opened 5 years ago Closed 4 years ago

Crash in mozilla::layers::CompositorOGL::BindAndDrawQuads

Categories

(Core :: Graphics: Layers, defect, critical)

41 Branch
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla43
Tracking Status
firefox41 + fixed
firefox42 + verified
firefox43 + fixed

People

(Reporter: marcia, Assigned: jnicol)

Details

(4 keywords, Whiteboard: gfx-noted)

Crash Data

Attachments

(3 files, 1 obsolete file)

Seen while running the latest Fennec beta 20150811185251.

STR:
1. Load http://flyanddine.boardingarea.com/genius-flight-hack-free-wi-fi-on-us-air-aa-delta-and-more/
2. Scroll back and forth on the page
3. Crash

https://crash-stats.mozilla.com/report/index/8bf85fa0-9481-448d-898e-c044f2150815

This is reproducible on my Nexus 6.
Adding crash signature. Since this crash I have also crashed scrolling other sites besides the one in Comment 1.
Crash Signature: [@ libGLESv2_adreno.so@0x17797c]
[Tracking Requested - why for this release]: Makes it almost impossible to use the Beta browser on some Android devices.

Here are the rest of the crash reports in this signature: https://crash-stats.mozilla.com/report/list?signature=libGLESv2_adreno.so%400x17797c&
Severity: normal → critical
Hi CJ,
The crash report shows that it's related to layerscope.
http://hg.mozilla.org/releases/mozilla-beta/annotate/6897f8e42fe2/gfx/layers/opengl/CompositorOGL.cpp#l1596
Assignee: nobody → cku
I think it's more like mGLContext->fDrawArrays() call, since LayerScope::SetLayerRects() doesn't call any gl function.
http://hg.mozilla.org/releases/mozilla-beta/annotate/6897f8e42fe2/gfx/layers/opengl/CompositorOGL.cpp#l1595
Assignee: cku → nobody
This crash came from an draw call summit at #11595
http://hg.mozilla.org/releases/mozilla-beta/annotate/6897f8e42fe2/gfx/layers/opengl/CompositorOGL.cpp#l1595

mGLContext->fDrawArrays(LOCAL_GL_TRIANGLES, 0, 6 * aQuads);
Adding topcrash keyword as this shows the top crash in beta crash stats - https://crash-stats.mozilla.com/topcrasher/products/FennecAndroid/versions/41.0b1?days=7
Keywords: topcrash
CJ will try to build the fennec version first.
Assignee: nobody → cku
Please help to figure out which check-in cause this problem.
Keywords: qawanted
I wonder if this is a signature mutation of bug 1177421
My Nexus 6 is running 5.1.1. I can see that it is pretty easy to crash pinching and zooming as well, especially on some pages.
Deassign from me since I am not that familiar with fennec. But I will still dig into it in this week. Please feel free to take it
Assignee: cku → nobody
Jamie, can you please look into this? I may be related to the other Nexus 6 nonsense and seems to be reproducible.
Flags: needinfo?(jnicol)
This got missed in the triage because it was already assigned.  Jamie is on PTO, should be able to look at it when back.
Assignee: nobody → jnicol
Whiteboard: gfx-noted
Back from PTO, looking at this now
Flags: needinfo?(jnicol)
Doesn't seem to be related to the other nexus 6 crashes.

I bisected and found this was introduced by https://hg.mozilla.org/mozilla-central/rev/7674044400c8. This is also present on aurora.

Nightly is okay, as it has been fixed by https://hg.mozilla.org/mozilla-central/rev/513d1660a8d4.

Next I will check if that fix can be ported to beta and aurora.
The patch from nightly applies cleanly to aurora and prevents the crash.
We had diverged from beta, however, so it also required https://hg.mozilla.org/mozilla-central/rev/28fac8d7cdde and a few small changes. Seems to prevent the crash on beta too.

Try run for beta to make sure it doesn't break anything: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3d8252b5df44

My work in the past few comments has been using the test case mentioned in comment 13. And although the patches I've mentioned 100% reliably introduced then prevented this crash occurring with that test case, from looking at them I'm not convinced they are directly responsible. This could well be related to the other nexus 6 crashes, and could hopefully provide some insight into what's going on there. I'll investigate further.
The nexus 6 will crash when we create many CompositingRenderTargetOGL's but do not use them. ("use" as in call glDrawArrays with it bound either as a texture source or fbo target.) Perhaps the driver is leaking in this circumstance?

The reason why commit 7674044400c8 unearthed this is because it added an early exit to CompositorOGL::DrawQuad, but with incorrect logic determining whether the quad could be culled. This lead to us incorrectly not calling glDrawArrays, causing the crash. Subsequent commits to nightly fixed the logic, meaning no incorrect early return, meaning glDrawArrays was called, meaning no crash.

I would suggest that we revert the bad commit on beta, and cherry-pick the fix commit from central to aurora. We could also port the two fixing commits from central to beta, but the branches have diverged. My try run in comment 19 attempting to do that looks awful. Milan, Snorp: thoughts?

Either way the underlying problem still exists, and could very well be the cause of the other nexus 6 crashes. Certainly many of the urls given in the other tickets create offscreen surfaces, whether or not they draw to or from them is what I should find out.
Flags: needinfo?(snorp)
Flags: needinfo?(milan)
(In reply to Jamie Nicol [:jnicol] from comment #20)
> The reason why commit 7674044400c8 unearthed this is because it added an
> early exit to CompositorOGL::DrawQuad, but with incorrect logic determining
> whether the quad could be culled. This lead to us incorrectly not calling
> glDrawArrays, causing the crash. Subsequent commits to nightly fixed the
> logic, meaning no incorrect early return, meaning glDrawArrays was called,
> meaning no crash.

Incorrect or correct early return are all skip some glDrawArrays().
If we are trying to create an CompositingRenderTargetOGL for intermediate surface and we find that all drawQuad() to this surface is not in the visible region, we skip all of them. I think this is the correct early return, but we still get crash. Is my understanding correct?
Flags: needinfo?(jnicol)
Yes, sorry if I wasn't clear enough. We will crash if we never call glDrawArrays with the surface bound as either texture or target. Whether or not the early return was "correct", because the quad is outside of the visible region, is irrelevant to whether or not it crashes. However, in this case, the incorrect early return logic was making the crash much more likely.
Flags: needinfo?(jnicol)
(In reply to Jamie Nicol [:jnicol] from comment #20)
> ...
> 
> I would suggest that we revert the bad commit on beta, and cherry-pick the
> fix commit from central to aurora. We could also port the two fixing commits
> from central to beta, but the branches have diverged. My try run in comment
> 19 attempting to do that looks awful. Milan, Snorp: thoughts?

I like the idea of doing what you're suggesting; maybe another try, there were some other patches in that push from comment 19, perhaps they were partially responsible for the ugliness?
Flags: needinfo?(milan)
I looked at the top 25 crashes for 41.0b and do not see this signature in there. It seems too late to fix this for 41.
Flags: needinfo?(milan)
(In reply to Ritu Kothari (:ritu) from comment #25)
> I looked at the top 25 crashes for 41.0b and do not see this signature in there.

This is a Firefox for Android crash, did you look at stats for that product or for desktop?
This makes Firefox for Android practically unusable for me on a Google Nexus 6 device. If it's just me, then so be it, but I doubt that's the case, and thus do not feel we can ship with this bug :(
Using Socorro Supersearch I found that this is #7 @ 2.76% for FennecAndroid in Beta, #3 @ 15.87% if I just look at Nexus 6 users. The Nexus 6 is our second most common device on Beta @ 3.46% and our 22nd most common device in Release @ 0.61%. Given this data I'm inclined to agree with Johnny and suggest we should not ship Fennec 41 with this bug.
Kevin, what's your take from an Android QA POV?

I'm setting this back from wontfix to affected for 41, given the comments above. Ritu, please take a look at those when re-evaluating.
Flags: needinfo?(kbrosnan)
(In reply to Johnny Stenback  (:jst, jst@mozilla.com) from comment #27)
> This makes Firefox for Android practically unusable for me on a Google Nexus
> 6 device. If it's just me, then so be it, but I doubt that's the case, and
> thus do not feel we can ship with this bug :(

Agreed - I cannot use beta with my Nexus 6 at all with this bug present.
We're hitting (real?) failure on try with the fix suggested in comment 19 (https://treeherder.mozilla.org/#/jobs?repo=try&revision=8764a8183f4e).  Can somebody with this failing for them grab the build from the try run and at least see if the problem goes away?  Jamie is away until Tuesday, trying to keep this one moving in the meantime.
https://ftp.mozilla.org/pub/firefox/try-builds/jnicol@mozilla.com-8764a8183f4e/try-android-api-11/fennec-41.0.en-US.android-arm.apk fails to install on my Nexus 6 with an "App not installed" error after it looks like the install process starts up and spins for a few seconds :(
(In reply to Johnny Stenback  (:jst, jst@mozilla.com) from comment #32)
> https://ftp.mozilla.org/pub/firefox/try-builds/jnicol@mozilla.com-
> 8764a8183f4e/try-android-api-11/fennec-41.0.en-US.android-arm.apk fails to
> install on my Nexus 6 with an "App not installed" error after it looks like
> the install process starts up and spins for a few seconds :(

Do you have a regular Nightly installed? You may need to uninstall that one first.
Flags: needinfo?(snorp)
Ah, had to uninstall Firefox beta, after that I was able to install the try build. Thanks!
Ok, been beating on the try build here and have yet to see a crash! With the beta channel I would've seen 20 crashes by now...
That's great news - the bad news is, there is still that Linux try failure, and it was there in the previous run as well.  It doesn't fail for me locally on a linux debug (beta) build.  :snorp, can you try a build locally and see if that test fails for you?
Flags: needinfo?(snorp)
KaiRo, my bad that I did not review the FennecAndroid top crashes and perhaps looked at Firefox instead. However, I am surprised this was never mentioned in the Mobile stability section during channel meetings. Anyway, given that the try build looks good for JST, we could consider taking a fix for 41RC.
Flags: needinfo?(kairo)
It is fairly bad for the affected population. I suspect we have been shipping this crash for a number of releases just as a different signature, see bug 1177421 which has very similar STR. When it comes to graphics fixes I am a bit leery of quick uplifts.
Flags: needinfo?(kbrosnan)
I agree with a "quick uplift" danger, but this is a regression of bug 1170966, introduced in 41, so I'm not as leery as usual.
(In reply to Ritu Kothari (:ritu) from comment #37)
> However, I am surprised this was never
> mentioned in the Mobile stability section during channel meetings.

I was surprised as well that there is actually an issue we haven't recognized before. I guess that both Kevin and me for some reason looked over it among the overall decent crash rates and the Kindle thing on beta that created a bit of a mess crash-stats-wise.
Flags: needinfo?(kairo)
:jst has been running with the try run and while the frequency of the crashes has gone way down, the crash isn't gone completely.  However, getting it to that lower frequency is probably good enough for shipping. If we are crashing because of the optimization (and comment 20, comment 21, comment 22 seem to suggest that) it stands to reason that the frequency of crashes would increase when we do more agressive optimizations and "early returns".  It also stands to reason that this particular signature is Adreno 420 only - I wonder if we have similar signatures for other chipsets? (Adreno 420 seems to be in Google Nexus 6, Samsung Galaxy S5 LTE-A, Samsung Galaxy Note 4, Samsung Galaxy Note Edge, LG G3 Cat. 6, Amazon Fire HDX 8.9.)

How much performance improvements are we getting from the early returns?  What would it take to completely remove those early returns?  We could set it up for these devices, if what we're talking about here is a driver bug.
Flags: needinfo?(jnicol)
Flags: needinfo?(hshih)
The "early return" could save the ogl driver time, since we skip some ogl function call especially when we have a lot of tile quads. The most noticeable improvement is that we only send the visible quad to layerscope[1] tool, and then we save a lot of texture transmission effort.

I will try to reproduce the crash first, then check the rect argument first. Maybe we pass the incorrect rect buffer here.

We use android ndk, so I also could dump the call stack using:
#include <utils/CallStack.h>
using namespace android;
extern "C" void dump_stack_android(void)
{
  CallStack stack;
  stack.update();
  stack.dump();
}
 
[1]
https://wiki.mozilla.org/Platform/GFX/LayerScope
Finally, I can build the fennec at my linux pc.
Please check https://bugzilla.mozilla.org/show_bug.cgi?id=1204459#c1

I will put more log and test again at nexus6 tomorrow.
Note that we build our last beta for 41 today and the release builds later this week, so we are in a time crunch for that release.
Milan, I will gtb 41RC today, in the next hour or so. Do you think I should wait for a patch that needs uplifting later today? Just wondering if this is ready or needs more work.
Flags: needinfo?(milan)
We don't have a patch that's better than what's on try in comment 31.  If we can land that on Beta, and "ignore" any test failures it may cause, that's the best thing we have right now.  It does improve things (anecdotally), and if the test failure is not a real indicator of a problem, that's the right thing to do.
Flags: needinfo?(milan)
Jerry, would you be able to comment on whether the test failures are due to a real bug or perhaps tests needing update? I would prefer to rule out any test issues and re-consider uplifting this to 41 RC2. 

Would you please be able to redirect to test owners if that is not you? Thanks!
Version: 38 Branch → 41 Branch
In person conversation with Jerry (and I tend to agree) is that the change is unrelated to the test failures, so other than the fact that they're showing up, we don't think they would have been caused by this change.  Famous last words perhaps.
Flags: needinfo?(hshih)
Attached patch Fix culling logic (obsolete) — Splinter Review
Here is the patch from try uploaded to bugzilla. This patch fixes some incorrect logic - without it there are potential situations where we would not render when we are supposed to. I agree with Jerry and Milan that these test failures do not seem related. I will test more today.

I did another try run with the patch - https://treeherder.mozilla.org/#/jobs?repo=try&revision=756aa25faf45
And for comparison I did one without the patch - https://treeherder.mozilla.org/#/jobs?repo=try&revision=a6b5288a23c6

They are still ongoing at this timne, but seem to have the same errors. (Perhaps I am simply not submitting to try the correct way for mozilla-beta?)

Now importantly this patch also seems to reduce the frequency of crashes on the nexus 6, though sort of by accident. Unfortunately it doesn't fix the crashes, and I still haven't worked out the reason behind the crashes. It appears to be more nuanced than what I described in comment 20. I think it might be a driver bug and not a regression on our part, but have been unable to prove that.

I do not have any hard evidence on how much more common crashes are without this patch, but in my experience I can crash fennec very easily without the patch, and incredibly rarely with it (hence my difficulty in finding the underlying problem). So I believe it worthwhile to land.
Flags: needinfo?(jnicol)
Attachment #8661732 - Flags: review?(hshih)
I have discovered that the crash was occuring because of the call to glDeleteFramebuffers in CompositingRenderTargetOGL's destructor. Likely a driver issue. Calling glFlush before glDeleteFramebuffers prevents the crash from occuring.

I am currently working on a patch to call glFlush before glDeleteFramebuffers on affected devices (which seems to be Adreno 420 only). While I don't think it will fix all nexus 6 crashes it will fix more than the previous patch and will allow us to use the early return optimisation. It should also be zero risk.
Comment on attachment 8661732 [details] [diff] [review]
Fix culling logic

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

Thanks.
Attachment #8661732 - Flags: review?(hshih) → review+
(In reply to Jamie Nicol [:jnicol] from comment #51)
> I have discovered that the crash was occuring because of the call to
> glDeleteFramebuffers in CompositingRenderTargetOGL's destructor. Likely a
> driver issue. Calling glFlush before glDeleteFramebuffers prevents the crash
> from occuring.
> 
> I am currently working on a patch to call glFlush before
> glDeleteFramebuffers on affected devices (which seems to be Adreno 420
> only). While I don't think it will fix all nexus 6 crashes it will fix more
> than the previous patch and will allow us to use the early return
> optimisation. It should also be zero risk.

Cool!!!
Jamie, could you share that how to find the "glDeleteFramebuffers" problem?
I have try the jimdb for fennec. When the gdb catches the sigserv signal, the call-stack is invalid. We don't have the ogl driver symbol file.
What symptom have you looked?
Flags: needinfo?(jnicol)
(In reply to Jerry Shih[:jerry] (UTC+8) from comment #53)
> (In reply to Jamie Nicol [:jnicol] from comment #51)
> > I have discovered that the crash was occuring because of the call to
> > glDeleteFramebuffers in CompositingRenderTargetOGL's destructor. Likely a
> > driver issue. Calling glFlush before glDeleteFramebuffers prevents the crash
> > from occuring.
> > 
> > I am currently working on a patch to call glFlush before
> > glDeleteFramebuffers on affected devices (which seems to be Adreno 420
> > only). While I don't think it will fix all nexus 6 crashes it will fix more
> > than the previous patch and will allow us to use the early return
> > optimisation. It should also be zero risk.
> 
> Cool!!!
> Jamie, could you share that how to find the "glDeleteFramebuffers" problem?
> I have try the jimdb for fennec. When the gdb catches the sigserv signal,
> the call-stack is invalid. We don't have the ogl driver symbol file.
> What symptom have you looked?

Yes, same for me. It was just trial and error and a lot of time spent.
It struck me as really odd that by *not* calling certain functions we caused the crash. So I tried looking to see if not calling other functions would fix it. Eventually I tried commenting out the glDeleteFramebuffers and it didn't crash that time.
Flags: needinfo?(jnicol)
This patch calls glFlush before glDeleteFramebuffers. I can't promise this fixes all nexus 6 crashes but it does fix some certainly.

Try run here: https://treeherder.mozilla.org/#/jobs?repo=try&revision=de87625c68f7

I've obsoleted the previous patch because this will prevent at least as many crashes as it does. The previous patch does however still fix the incorrect culling logic. But since we have no bugs about that being incorrect (on all devices, not just ones that crash instead) it is perhaps not worth the risk.

I asked snorp to review and he said jgilbert should maybe have a look too. If jerry and jst could test the apk from try that would be very helpful too.
Attachment #8661732 - Attachment is obsolete: true
Flags: needinfo?(jst)
Flags: needinfo?(hshih)
Attachment #8661909 - Flags: review?(snorp)
Attachment #8661909 - Flags: review?(jgilbert)
Comment on attachment 8661909 [details] [diff] [review]
0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch

Approval Request Comment
[Feature/regressing bug #]:
This bug

[User impact if declined]:

Frequent crashes and basically unusable browser for all Nexus 6 / Adreno 420 users.

[Describe test coverage new/current, TreeHerder]:

mozilla-beta with this patch on top:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=de87625c68f7

[Risks and why]: 

Only users with the specific devices will be affected.

[String/UUID change made/needed]:

No change
Attachment #8661909 - Flags: approval-mozilla-beta?
Milan, would you be able to provide your assessment of the patch and risk associated? Based on my chat with Jamie, he feels this patch is the right thing to do and has low risk associated. Given that this will be uplifted to RC2, I would feel much more confident if I had your input on this as well. Many thanks!
Flags: needinfo?(milan)
Comment on attachment 8661909 [details] [diff] [review]
0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch

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

Patch looks good to me

I looked through some of the other crash signatures with 'libGLESv2_adreno.so', and nearly all of those were on the 420, so I have a lot of hope for this patch.
Attachment #8661909 - Flags: review?(snorp) → review+
(In reply to Ritu Kothari (:ritu) from comment #57)
> Milan, would you be able to provide your assessment of the patch and risk
> associated? Based on my chat with Jamie, he feels this patch is the right
> thing to do and has low risk associated. Given that this will be uplifted to
> RC2, I would feel much more confident if I had your input on this as well.
> Many thanks!

This is a low risk. At worst things will be somewhat slower on the affected devices.
Flags: needinfo?(milan)
Comment on attachment 8661909 [details] [diff] [review]
0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch

[Triage Comment] This is a top crash on Fennec. Many thanks to Jamie for pushing on this all day yesterday and getting to the bottom of it and then proposing a patch that is well-contained with a low risk associated. Let's uplift to m-r so it is included in RC2.
Attachment #8661909 - Flags: approval-mozilla-beta? → approval-mozilla-release+
Does this patch need to go anywhere else aside from 41?
Flags: needinfo?(jnicol)
I think we actually want this patch everywhere, right?
Flags: needinfo?(snorp)
Attachment #8661909 - Flags: review?(jgilbert) → review+
Comment on attachment 8661909 [details] [diff] [review]
0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch

Yes, we do want this patch everywhere.

(This turned out to be quite an epic bug; had Jerry debugging on Johnny's phone in Taipei, Jamie in London, we almost had a 24 hour watch on it.)
Flags: needinfo?(jst)
Flags: needinfo?(jnicol)
Flags: needinfo?(hshih)
Attachment #8661909 - Flags: approval-mozilla-beta?
Attachment #8661909 - Flags: approval-mozilla-aurora?
We will try this patch locally on Johnny's phone later.
Thanks.
Until now, We haven't got the crash with attachment 8661909 [details] [diff] [review] on on Johnny's phone.
Spent a good chunk of time browsing around like I have been when reproducing this crash before and failed. This is with the build that I got from Jerry earlier today, so looks like you guys nailed this one! Well done.
Hi, this failed to apply for mozilla-inbound:

applying 0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch
patching file gfx/gl/GLContext.h
Hunk #2 FAILED at 2291
1 out of 3 hunks FAILED -- saving rejects to file gfx/gl/GLContext.h.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working directory
errors during apply, please fix and refresh 0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch

could you take a look, thanks!
Flags: needinfo?(jnicol)
Keywords: checkin-needed
Straightforward rebase, the implementation of GLContext::fDeleteFramebuffers had just been moved from header to source.
Flags: needinfo?(jnicol)
Keywords: checkin-needed
Comment on attachment 8661909 [details] [diff] [review]
0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch

Approving for uplift to Aurora. If it lands this week, then post merge this will also be in 42 Beta. Removing the beta flag as this is already in Beta41.
Attachment #8661909 - Flags: approval-mozilla-beta?
Attachment #8661909 - Flags: approval-mozilla-aurora?
Attachment #8661909 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/mozilla-central/rev/1bfcd86512b4
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla43
(In reply to Ritu Kothari (:ritu) from comment #71)
> Comment on attachment 8661909 [details] [diff] [review]
> 0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch
> 
> Approving for uplift to Aurora. If it lands this week, then post merge this
> will also be in 42 Beta. Removing the beta flag as this is already in Beta41.

I'm not seeing how this is already in beta? I don't see a comment in this bug where this landed on the beta branch, or am I missing something?
(In reply to Johnny Stenback  (:jst, jst@mozilla.com) from comment #74)
> (In reply to Ritu Kothari (:ritu) from comment #71)
> > Comment on attachment 8661909 [details] [diff] [review]
> > 0001-Bug-1194923-Call-glFlush-before-glDeleteFramebuffers.patch
> > 
> > Approving for uplift to Aurora. If it lands this week, then post merge this
> > will also be in 42 Beta. Removing the beta flag as this is already in Beta41.
> 
> I'm not seeing how this is already in beta? I don't see a comment in this
> bug where this landed on the beta branch, or am I missing something?

I landed this to mozilla-release in https://hg.mozilla.org/releases/mozilla-release/rev/f4bfcf6b785b (Comment 61), after beta41 had already merged to release (to prepare for the official, final release of 41), so it only needed to land on trunk (43) and aurora (42) to hit everywhere.
Ah, perfect. I was looking for beta and thus missed that. Thanks!
Verified as fixed on Nexus 6(Android 5.1.1) on Firefox 42 Beta 1.
Was able to reproduce reliably with the site from comment 13 on Firefox 41 Beta 10, on Nexus 6
Hi, is it supposed to be fixed on any public release?
I can still reproduce this on all versions. Stable, Beta and Nightly.
For example charts on https://www.tradingview.com/ can crash it everytime with this error.
Yes, this is supposed to be fixed on Nightly and Stable, but not Beta yet (due to the timing of the fix relative to the release) AFAIK. I'm unable to reproduce a crash, even on beta, on that site :(
I had to delete Firefox applications data to got it working. It's weird but it works now :)
You need to log in before you can comment on or make changes to this bug.