(Following up comment #9) I may have spoken too soon. Just now I managed to trigger a "BindDataBuffer" (`0x067900fc`) crash: bp-27c18015-7f42-4f41-b037-1f03d0210605 I did it by changing the "resource id" in the "BindDataBuffer" (`0x00`) tag from the one originally present to one that had already been present at least once in a "ResourceList" (0x85) tag's list of "attachments". The resource was valid (not deleted or malformed), but just the wrong kind. "Resources" (created by `IOAccelResourceCreate()` or `IOAccelResourceCreateDataBuffer()` in the `IOAccelResource` private framework) can have various types. Those created by `IOAccelResourceCreateDataBuffer()` seem to always have type `0xa`. And these are (normally) the only ones whose "resource ids" are present in the "BindDataBuffer" tag. Those created by `IOAccelResourceCreate()` can have many different types, but never `0xa`. These other types are what's normally present in the "ResourceList" tag's list of attachments. I haven't yet managed to trigger a "ResourceList" (`0x1be385f9`) crash. When I tried changing one of this tag's resource ids (in its list of attachments) to one of type `0xa` (which had already been present at least once in a "BindDataBuffer" tag), I got another `0x067900fc` crash. Doing this didn't mess up the "ResourceList" tag. But apparently it *did* mess up that `0xa` resource (or objects linked to it) badly enough that it triggered a crash the next time it (or one of its linked objects) was used in a "BindDataBuffer" tag. I'm not sure where that leaves us. I *may* have found out that they're caused by the wrong kind of resource being present in a tag. But I can't really be sure of that until I manage to use the same strategy to trigger `0x1be385f9` crashes. If I'm right, these crashes are caused by a bug or bugs in Apple's user-mode AMDRadeonX4000 graphics drivers. That's good, because it's a lot easier to figure out user-mode bugs (using tools like [HookCase](https://github.com/steven-michaud/HookCase)) than it is to figure out kernel-mode bugs. But it still won't be easy. This bug will only have moved from "almost impossible" to "very difficult".
Bug 1713230 Comment 13 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(Following up comment #9) I may have spoken too soon. Just now I managed to trigger a "BindDataBuffer" (`0x067900fc`) crash: bp-27c18015-7f42-4f41-b037-1f03d0210605 I did it by changing the "resource id" in the "BindDataBuffer" (`0x00`) tag from the one originally present to one that had already been present at least once in a "ResourceList" (0x85) tag's list of "attachments". The resource was valid (not deleted or malformed), but just the wrong kind. "Resources" (created by `IOAccelResourceCreate()` or `IOAccelResourceCreateDataBuffer()` in the `IOAccelResource` private framework) can have various types. Those created by `IOAccelResourceCreateDataBuffer()` seem to always have type `0xa`. And these are (normally) the only ones whose "resource ids" are present in the "BindDataBuffer" tag. Those created by `IOAccelResourceCreate()` can have many different types, but never `0xa`. These other types are what's normally present in the "ResourceList" tag's list of attachments. I haven't yet managed to trigger a "ResourceList" (`0x1be385f9`) crash. When I tried changing one of this tag's resource ids (in its list of attachments) to one of type `0xa` (which had already been present at least once in a "BindDataBuffer" tag), I got another `0x067900fc` crash. Doing this didn't mess up the "ResourceList" tag. But apparently it *did* mess up that `0xa` resource (or objects linked to it) badly enough that it triggered a crash the next time it (or one of its linked objects) was used in a "BindDataBuffer" tag. I'm not sure where that leaves us. I *may* have found out that they're caused by the wrong kind of resource's id being present in a tag. But I can't really be sure of that until I manage to use the same strategy to trigger `0x1be385f9` crashes. If I'm right, these crashes are caused by a bug or bugs in Apple's user-mode AMDRadeonX4000 graphics drivers. That's good, because it's a lot easier to figure out user-mode bugs (using tools like [HookCase](https://github.com/steven-michaud/HookCase)) than it is to figure out kernel-mode bugs. But it still won't be easy. This bug will only have moved from "almost impossible" to "very difficult".