Bugzilla

Recent developments, post comment #9, made me temporarily more optimistic. But now I think what I said there is largely correct. Apple's customized error codes did allow me to learn more about what's going on with this bug's crashes. But it's still not actionable, and I'm not going to pursue this research any further. Only some big new insight or piece of information will change that.

Here's where things stand, as I now see it:

This bug's error codes (`0x1be385f9` and `0x067900fc`) correspond to two distinct kinds of crash. They're probably not related.

`0x1be385f9` crashes probably happen because of the Apple bug or design flaw that I outlined in comment #18. I suspect they're much more likely to happen on systems that drive lots of pixels -- especially those with several external monitors. They're real "out of memory" bugs, at least in a sense -- they happen when a system is close to the limits of available VRAM and wireable RAM. But they can happen on systems with lots of "available physical memory". They're kernel-mode "out of memory" bugs, as distinct from user-mode "out of memory" bugs.

`0x067900fc` bugs are harder to understand. They *might* be caused by user-mode graphics drivers attaching the wrong kind of `IOAccelResource` object to a "BindDataBuffer" tag (of type `0x0`). That, so far, is the only way I've found to trigger them. But I could have missed something.

Recent developments, post comment #9, made me temporarily more optimistic. But now I think what I said there is largely correct. Apple's customized error codes did allow me to learn more about what's going on with this bug's crashes. But it's still not actionable, and I'm not going to pursue this research any further. Only some big new insight or piece of information will change that.

Here's where things stand, as I now see it:

This bug's error codes (`0x1be385f9` and `0x067900fc`) correspond to two distinct kinds of crash. They're probably not related.

`0x1be385f9` crashes probably happen because of the Apple bug or design flaw that I outlined in comment #18. I suspect they're much more likely to happen on systems that drive lots of pixels -- especially those with several external monitors. They're real "out of memory" bugs, at least in a sense -- they happen when a system is close to the limits of available VRAM and wireable RAM. But they can happen on systems with lots of "available physical memory". They're kernel-mode "out of memory" bugs, as distinct from user-mode "out of memory" bugs.

`0x067900fc` crashes are harder to understand. They *might* be caused by user-mode graphics drivers attaching the wrong kind of `IOAccelResource` object to a "BindDataBuffer" tag (of type `0x0`). That, so far, is the only way I've found to trigger them. But I could have missed something.

Recent developments, post comment #9, made me temporarily more optimistic. But now I think what I said there is largely correct. Apple's customized error codes did allow me to learn more about what's going on with this bug's crashes. But it's still not actionable, and I'm not going to pursue this research any further. Only some big new insight or piece of information will change that.

Here's where things stand, as I now see it:

This bug's error codes (`0x1be385f9` and `0x067900fc`) correspond to two distinct kinds of crash. They're probably not related.

`0x1be385f9` crashes probably happen because of the Apple bug or design flaw that I outlined in comment #18. I suspect they're much more likely to happen on systems that drive lots of pixels -- especially those with several external monitors. They're real "out of memory" crashes, at least in a sense -- they happen when a system is close to the limits of available VRAM and wireable RAM. But they can happen on systems with lots of "available physical memory". They're kernel-mode "out of memory" crashes, as distinct from user-mode "out of memory" crashes.

`0x067900fc` crashes are harder to understand. They *might* be caused by user-mode graphics drivers attaching the wrong kind of `IOAccelResource` object to a "BindDataBuffer" tag (of type `0x0`). That, so far, is the only way I've found to trigger them. But I could have missed something.

Recent developments, post comment #9, made me temporarily more optimistic. But now I think what I said there is largely correct. Apple's customized error codes did allow me to learn more about what's going on with this bug's crashes. But it's still not actionable, and I'm not going to pursue this research any further. Only some big new insight or piece of information will change that.

Here's where things stand, as I now see it:

This bug's error codes (`0x1be385f9` and `0x067900fc`) correspond to two distinct kinds of crash. They're probably not related.

`0x1be385f9` (aka `0xfffffff9/-7`) crashes probably happen because of the Apple bug or design flaw that I outlined in comment #18. I suspect they're much more likely to happen on systems that drive lots of pixels -- especially those with several external monitors. They're real "out of memory" crashes, at least in a sense -- they happen when a system is close to the limits of available VRAM and wireable RAM. But they can happen on systems with lots of "available physical memory". They're kernel-mode "out of memory" crashes, as distinct from user-mode "out of memory" crashes.

`0x067900fc` (aka `0xfffffffc/-4`) crashes are harder to understand. They *might* be caused by user-mode graphics drivers attaching the wrong kind of `IOAccelResource` object to a "BindDataBuffer" tag (of type `0x0`). That, so far, is the only way I've found to trigger them. But I could have missed something.