This bug was filed from the Socorro interface and is report bp-e4031095-cb6b-4470-b25a-2c4220180117. ============================================================= Mac and Linux signature that started on Linux using 20180116220110: http://bit.ly/2ET9eHe. There are also crashes in Windows using [@ rayon_core::job::{{impl}}::execute<T> ] Top 10 frames of crashing thread: 0 libmozglue.dylib mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:33 1 libmozglue.dylib abort memory/mozalloc/mozalloc_abort.cpp:80 2 XUL std::panicking::rust_panic src/libpanic_abort/lib.rs:59 3 XUL std::panicking::rust_panic_with_hook src/libstd/panicking.rs:593 4 XUL std::panicking::begin_panic<alloc::string::String> src/libstd/panicking.rs:538 5 XUL std::panicking::begin_panic_fmt src/libstd/panicking.rs:522 6 XUL core::panicking::panic_fmt src/libstd/panicking.rs:498 7 XUL core::panicking::panic_bounds_check src/libcore/panicking.rs:58 8 XUL rayon_core::job::{{impl}}::execute<closure> gfx/webrender_bindings/src/bindings.rs 9 XUL rayon_core::registry::{{impl}}::wait_until<rayon_core::latch::CountLatch> third_party/rust/rayon-core/src/job.rs:55 =============================================================

The crash reason for these crashes on Nightly is "index out of bounds: the len is 0 but the index is 0". This is the #5 top crash on OSX for the 1-17 Nightly, though that's with only 5 crashes.

Bug 1431711 has STR (I haven't tried it myself): (In reply to Safwan Rahman (:safwan) from comment #0) > # Open Devtools > # Go to JS debugger > # Add a breakpoint to any javascript > # Reload the page >

I had this happen to me without devtools; I received an email from Wordpress.com asking for subscription confirmation in GMail, clicked the thread to open it and then clicked the link to confirm. However, clicking that link again after restarting the browser didn't trigger it again.

Hmm, setting breakpoints doesn't seem to do anything for me. Possibly fixed?

I observed this crash in a build from 2/1: https://crash-stats.mozilla.com/report/index/8c4ab6c8-1e9a-4a59-810c-8b0fe0180201

Crashes with this signature in 2/1 build might be a variant of bug 1434994, which is a top crash related to some Rust code.

(In reply to Andrew McCreight [:mccr8] from comment #8) > Crashes with this signature in 2/1 build might be a variant of bug 1434994, > which is a top crash related to some Rust code. To be clear, the fix I pushed for that bug would only affect ARM. I believe my usage of relaxed atomic loads/stores in a patch from a few days ago was to blame for the android crashes, but x86 is immune to that issue/

Ah, ok. I saw this signature in the top 10 on Android, which is what I was referring to, but it looks like jdm's crash is on OSX, so it is likely unrelated.

I'm seeing this semi-regularly when opening up one of my slack teams in the browser.

This is the #4 Windows topcrash in Nightly 20180203220331, with 27 occurrences.

This might have been fixed ~yesterday incidentally by https://bugzilla.mozilla.org/show_bug.cgi?id=1362115 (fixed a crash with the same panic reason)

Nothing submitting a crash report has a buildid later than Feb 06, so I'm marking this fixed as I predicted.

I was able to reproduce this crash (with STR from comment 2) using an affected Nightly build (2018-01-18) on Ubuntu 16.04 x64 and macOS 10.13, but it appears to have a different signature: - https://crash-stats.mozilla.com/report/index/8109c1a5-8fa9-4d0f-b10b-60bb40180328 I cannot reproduce it anymore on latest Beta 60.0b7 (20180326164103) after setting the "gfx.webrender.enabled" pref to true, running Win 10 x64, macOS 10.13 and Ubuntu 16.04 x64. Just to make sure that this bug is also fixed on your side and because it crashed on my machine with a different signature, Safwan could you please help us verify this bug as well.

I will mark this bug as verified fixed per comment 15, and the fact that, there are no crash signatures submitted in the crash stats, after this fix landed in FF 60.