Bugzilla

(Following up comment #16)

The same "slight corruption" also triggers `0x1be385f9` crashes when used with `IOAccelResource` objects of type `0x40` ("Standard"). These objects are much more common than "VidMemShared" objects, and Firefox can't do without them. Some of them are also much larger. So (presumably) avoiding the use of "VidMemShared" objects won't help here. And my (guarded) optimism in comment #16 was misplaced.

By the way, my "slight corruption" was to drastically increase the size of a resource object's "resident size" -- the amount of space it takes up (in kernel memory) when it's "wired" into VRAM (GPU RAM) or system memory (ordinary RAM). Doing this doesn't stop an `IOAccelResource` object from being created (by `IOAccelResourceCreate()` in user-mode code). But it does cause `IOAccelResource2::prepare()` to fail in kernel-mode code while processing a `ResourceList` tag (type `0x0`) containing this object's resource id.

This is a Apple bug or design flaw. `IOAccelResourceCreate()` communicates directly with kernel-mode code, which could call `IOAccelResource2::prepare()` and return an error if it fails. My tests have shown that `IOAccelResourceCreate()` failures rarely (or ever) cause crashes. But `IOAccelResource2::prepare()` failures always trigger crashes when called via user-mode calls to `gpusSubmitDataBuffers()`.

(Following up comment #16)

The same "slight corruption" also triggers `0x1be385f9` crashes when used with `IOAccelResource` objects of type `0x40` ("Standard"). These objects are much more common than "VidMemShared" objects, and Firefox can't do without them. Some of them are also much larger. So (presumably) avoiding the use of "VidMemShared" objects won't help here. And my (guarded) optimism in comment #16 was misplaced.

By the way, my "slight corruption" was to drastically increase the size of a resource object's "resident size" -- the amount of space it takes up (in kernel memory) when it's "wired" into VRAM (GPU RAM) or system memory (ordinary RAM). Doing this doesn't stop an `IOAccelResource` object from being created (by `IOAccelResourceCreate()` in user-mode code). But it does cause `IOAccelResource2::prepare()` to fail in kernel-mode code while processing a `ResourceList` tag (type `0x0`) containing this object's resource id.

This is a Apple bug or design flaw. `IOAccelResourceCreate()` communicates directly with kernel-mode code, which could call `IOAccelResource2::prepare()` and return an error if it fails. My tests have shown that `IOAccelResourceCreate()` failures rarely (if ever) cause crashes. But `IOAccelResource2::prepare()` failures always trigger crashes when called via user-mode calls to `gpusSubmitDataBuffers()`.

(Following up comment #16)

The same "slight corruption" also triggers `0x1be385f9` crashes when used with `IOAccelResource` objects of type `0x40` ("Standard"). These objects are much more common than "VidMemShared" objects, and Firefox can't do without them. Some of them are also much larger. So (presumably) avoiding the use of "VidMemShared" objects won't help here. And my (guarded) optimism in comment #16 was misplaced.

By the way, my "slight corruption" was to drastically increase the size of a resource object's "resident size" -- the amount of space it takes up (in kernel memory) when it's "wired" into VRAM (GPU RAM) or system memory (ordinary RAM). Doing this doesn't stop an `IOAccelResource` object from being created (by `IOAccelResourceCreate()` in user-mode code). But it does cause `IOAccelResource2::prepare()` to fail in kernel-mode code while processing a `ResourceList` tag (type `0x85`) containing this object's resource id.

This is a Apple bug or design flaw. `IOAccelResourceCreate()` communicates directly with kernel-mode code, which could call `IOAccelResource2::prepare()` and return an error if it fails. My tests have shown that `IOAccelResourceCreate()` failures rarely (if ever) cause crashes. But `IOAccelResource2::prepare()` failures always trigger crashes when called via user-mode calls to `gpusSubmitDataBuffers()`.

(Following up comment #16)

The same "slight corruption" also triggers `0x1be385f9` crashes when used with `IOAccelResource` objects of type `0x40` ("Standard"). These objects are much more common than "VidMemShared" objects, and Firefox can't do without them. Some of them are also much larger. So (presumably) avoiding the use of "VidMemShared" objects won't help here. And my (guarded) optimism in comment #16 was misplaced.

By the way, my "slight corruption" was to drastically increase a resource object's "resident size" -- the amount of space it takes up (in kernel memory) when it's "wired" into VRAM (GPU RAM) or system memory (ordinary RAM). Doing this doesn't stop an `IOAccelResource` object from being created (by `IOAccelResourceCreate()` in user-mode code). But it does cause `IOAccelResource2::prepare()` to fail in kernel-mode code while processing a `ResourceList` tag (type `0x85`) containing this object's resource id.

This is a Apple bug or design flaw. `IOAccelResourceCreate()` communicates directly with kernel-mode code, which could call `IOAccelResource2::prepare()` and return an error if it fails. My tests have shown that `IOAccelResourceCreate()` failures rarely (if ever) cause crashes. But `IOAccelResource2::prepare()` failures always trigger crashes when called via user-mode calls to `gpusSubmitDataBuffers()`.