By looking to the failure logs, it seems that the crash is consistently happening after the test file is actually exiting.
On the other end, the particular test file that is failing is not always the same one, and so I doubt that the underlying issue is specific to something that the particular test is doing (but maybe it may be true for some of the tests), as an example one of the test file that is failing is test_ext_activityLog.js... which doesn't do really much on its own:
And so if this kind of failure is only happening on WebExtensions xpcshell tests, then it may be related to something that the WebExtensions framework does and not what the particular test file is doing.
Something special related to the WebExtension framework and these xpcshell test is that we spawn an extension process where the test extension runs (and in some other tests we also spawn some additional content process to mock webpages running in Firefox tabs),
and so I'm wondering if that could be related to the same failure happening in different tests from this test suite.
Also the logs collected for the failures tracked by orangefactor seems to suggest that there is still something during the shutdown that is trying to dispatch a message (which sounds definitely wrong):
\x07[Parent 30881, Gecko_IOThread] ###!!! ASSERTION: Failed NS_DispatchToMainThread() in shutdown; leaking: 'false', file /builds/worker/workspace/build/src/xpcom/threads/nsThreadUtils.cpp, line 243
INFO - PID 30881 | #01: NS_DispatchToMainThread(already_AddRefed<nsIRunnable>&&, unsigned int) [xpcom/threads/nsThreadUtils.cpp:242]
INFO - PID 30881 | #02: NS_DispatchToMainThread(nsIRunnable*, unsigned int) [xpcom/threads/nsThreadUtils.cpp:258]
INFO - PID 30881 | #03: mozilla::ipc::MessagePump::ScheduleWork() [ipc/glue/MessagePump.cpp:125]
INFO - PID 30881 | #04: MessageLoop::PostTask_Helper(already_AddRefed<nsIRunnable>, int) [ipc/chromium/src/base/message_loop.cc:402]
INFO - PID 30881 | #05: MessageLoop::PostTask(already_AddRefed<nsIRunnable>) [ipc/chromium/src/base/message_loop.cc:346]
INFO - PID 30881 | #06: mozilla::ipc::MessageChannel::OnChannelConnected(int) [ipc/glue/MessageChannel.cpp:2455]
INFO - PID 30881 | #07: mozilla::ipc::ProcessLink::OnChannelConnected(int) [ipc/glue/MessageLink.cpp:328]
INFO - PID 30881 | #08: IPC::Channel::ChannelImpl::ProcessIncomingMessages() [ipc/chromium/src/chrome/common/ipc_channel_posix.cc:571]
INFO - PID 30881 | #09: IPC::Channel::ChannelImpl::OnFileCanReadWithoutBlocking(int) [ipc/chromium/src/chrome/common/ipc_channel_posix.cc:822]
INFO - PID 30881 | #10: base::MessagePumpLibevent::OnLibeventNotification(int, short, void*) [ipc/chromium/src/base/message_pump_libevent.cc:244]
INFO - PID 30881 | #11: event_process_active_single_queue [ipc/chromium/src/third_party/libevent/event.c:1639]
INFO - PID 30881 | #12: event_base_loop [ipc/chromium/src/third_party/libevent/event.c:1961]
INFO - PID 30881 | #13: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) [ipc/chromium/src/base/message_pump_libevent.cc:337]
INFO - PID 30881 | #14: MessageLoop::RunInternal() [ipc/chromium/src/base/message_loop.cc:315]
INFO - PID 30881 | #15: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:289]
INFO - PID 30881 | #16: base::Thread::ThreadMain() [ipc/chromium/src/base/thread.cc:195]
INFO - PID 30881 | #17: ThreadFunc [ipc/chromium/src/base/platform_thread_posix.cc:42]
INFO - PID 30881 | #18: libpthread.so.0 + 0x76ba
But I'm not sure if it is something that may be actually triggered by the WebExtensions internals, the stacktrace suggests that the failure is triggered from the ipc layer, and so maybe someone that works on that layer may be able to help us to shade some light on the underlying reason (or suggest a strategy to get some additional detail that could help us with that).