Bugzilla

This bug is spun off from bug 1576767 comment 315 and following.

These crashes happen on Apple Intel graphics hardware, and are caused by at least one bug in the Apple graphics drivers specific to this hardware. Alexandru Trif found 100% effective STR for at least one of these bugs (bug 1576767 comment 315). Using that, I found a workaround for it.

Here's a fairly detailed description of Apple's bug, and of my workaround:

The "sideband buffer" is used by user-mode graphics drivers to schedule tasks in kernel-mode graphics drivers. This buffer fills up with "tokens", each of which corresponds to a single task. Periodically the tasks are all performed in a batch, and the sideband buffer is (temporarily) cleared. This is what happens on each call to `libGPUSupportMercury.dylib-gpusSubmitDataBuffers()` from user mode.

Each task uses certain resources, which need to be present for it to succeed. In the case of this bug's crashes on Intel hardware, a `Blit2D` token is added to the sideband buffer by a user-mode graphics driver. But before the kernel-mode driver can process the token (in a call to `AppleIntelHD5000Graphics-IGAccelGLContext::process_token_Blit2D()`), one of the resources required to perform the `Blit2D` task is deleted, as the result of a call to `mContext->gl->fDeleteTextures()` in `XUL-mozilla::WebGLTexture::~WebGLTexture()`. This also triggers a call to `libGPUSupportMercury.dylib-gpusSubmitDataBuffers()`, which tries to process the `Blit2D` token. But it only happens after the resource has been deleted. So the call to `AppleIntelHD5000Graphics-IGAccelGLContext::process_token_Blit2D()` fails, causing the kernel-mode driver to set the "context error" to `fffffffe/-2`. This in turn causes the user-mode call to crash with a signature containing `gpusGenerateCrashLog`. These crashes happen on all versions of macOS back to 10.12 (including macOS 11).

This kind of error should really be cleaned up by graphics driver code, either in user mode or in kernel mode. That doesn't happen in this case. But the problem is basically very simple. So we can "help" the driver around it by explicitly triggering a call to `libGPUSupportMercury.dylib-gpusSubmitDataBuffers()` (via a call to `mContext->gl->fFlush()`) before the call to `mContext->gl->fDeleteTextures()`.

This bug is spun off from bug 1576767 comment 315 and following.

These crashes happen on Apple Intel graphics hardware, and are caused by at least one bug in the Apple graphics drivers specific to this hardware. Alexandru Trif found 100% effective STR for one of these bugs (bug 1576767 comment 315). Using that, I found a workaround for it.

Here's a fairly detailed description of Apple's bug, and of my workaround:

The "sideband buffer" is used by user-mode graphics drivers to schedule tasks in kernel-mode graphics drivers. This buffer fills up with "tokens", each of which corresponds to a single task. Periodically the tasks are all performed in a batch, and the sideband buffer is (temporarily) cleared. This is what happens on each call to `libGPUSupportMercury.dylib-gpusSubmitDataBuffers()` from user mode.

Each task uses certain resources, which need to be present for it to succeed. In the case of this bug's crashes on Intel hardware, a `Blit2D` token is added to the sideband buffer by a user-mode graphics driver. But before the kernel-mode driver can process the token (in a call to `AppleIntelHD5000Graphics-IGAccelGLContext::process_token_Blit2D()`), one of the resources required to perform the `Blit2D` task is deleted, as the result of a call to `mContext->gl->fDeleteTextures()` in `XUL-mozilla::WebGLTexture::~WebGLTexture()`. This also triggers a call to `libGPUSupportMercury.dylib-gpusSubmitDataBuffers()`, which tries to process the `Blit2D` token. But it only happens after the resource has been deleted. So the call to `AppleIntelHD5000Graphics-IGAccelGLContext::process_token_Blit2D()` fails, causing the kernel-mode driver to set the "context error" to `fffffffe/-2`. This in turn causes the user-mode call to crash with a signature containing `gpusGenerateCrashLog`. These crashes happen on all versions of macOS back to 10.12 (including macOS 11).

This kind of error should really be cleaned up by graphics driver code, either in user mode or in kernel mode. That doesn't happen in this case. But the problem is basically very simple. So we can "help" the driver around it by explicitly triggering a call to `libGPUSupportMercury.dylib-gpusSubmitDataBuffers()` (via a call to `mContext->gl->fFlush()`) before the call to `mContext->gl->fDeleteTextures()`.