Crash report: https://crash-stats.mozilla.org/report/index/e424bb44-59a7-4a10-bae6-c9fc10250825

Reason:

SIGSEGV / SEGV_MAPERR

Top 3 frames:

0  ?  @0x00007f8728148790
1  libc.so.6  start_thread  /usr/src/debug/glibc/glibc/nptl/pthread_create.c:456
2  libc.so.6  __clone3  /usr/src/debug/glibc/glibc/sysdeps/unix/sysv/linux/x86_64/clone3.S:78

This is a bit of a peculiar crash, I was about to discard it as bad hardware until I looked a bit deeper and it's probably a genuine issue albeit a very hard one to debug. The stack fooled me into thinking this was a thread startup crash but it's a thread shutdown crash instead, here's what I found:

• The crashes are happening on every channel but increasingly on nightly
• The crashing thread on nightly is usually called CanvasR~,SHDACK. The SHDACK part is appended only on nightly when we acknowledge that the thread is shutting down
• The crashing line has been in libc for 20+ years and what it does is running the destructor for thread-local data
• Non-nightly crashes are hitting the same issue, they don't have the SHDACK part attached to the name but they're definitely still shutting down
• Many of the crashes are flagged a bit-flips, this is suspect because this looks a valid crash, so it might indicate that we're accessing something out-of-bounds (out-of-bounds accesses might be mistaken for bit-flips if they're using a power-of-2 offset).

To conclude, this looks like an issue triggered by using some TLS data within the canvas code. Not being familiar with the code it's hard to guess what's going on but this needs to be investigated.

The severity field is not set for this bug.
:lsalzman, could you have a look please?

For more information, please visit BugBot documentation.