Bugzilla

OK, I'm going to make a stab at describing the Apple "bug" that causes this bug's crashes. It's actually a design flaw, and is built deeply into macOS (and probably most/all other modern OSes). The problem is that run loops can be nested. And if things happen just right (or wrong), a nested run loop can destroy resources being used in the run loop it's nested on top of, leading to UAF crashes in the "lower" run loop.

As best I can tell there's no general fix. The problem needs to be addressed on a case-by-case basis, whenever it shows up. You need to find the resource that's triggering the crashes, and retain it before nesting a run loop that might destroy it. (It can be released after the nested run loop finishes.)

You might say that you should avoid nesting run loops. But that's not feasible. It's benefits far outweigh its disadvantages. For example, a modal run loop (using in dragging, let's say) might freeze up your app if you can't periodically nest other run loops on top of it.

In this bug's case, the way to address the problem is my patch from comment #72. The resource that's being destroyed in a "rogue" nested run loop is the (native) main window. The workaround is to hold a reference to this native window until its Mozilla counterpart (and owner) is destroyed -- until the nsCocoaWindow destructor is called.

It's just luck that Safari doesn't crash. It's not that Apple was aware of these crashes and secretly worked around them. It just happens to hold a reference to the main window long enough to prevent them from happening.

Chromium (and Google Chrome) crashes on accessing not the main window itself, but one of its NSView components. It, too, already holds a reference to the main window. But not, apparently, to all of its components.

Mozilla's apps (Firefox and Thunderbird) do crash on macOS 13 (and presumably also on lower versions), but with much lower frequency than on macOS 14 and 15. I'm not sure why. Chrome, as best I can tell, crashes with equal frequency on macOS 14 and 13. Google, of course, doesn't publish its crash stats. But my hook library "works" on Chrome just as easily on macOS 13 as on macOS 14.

My hook library deliberately nests a "rogue" run loop -- one that closes and destroys the main window. I'm still working on it. But I'll post it when I'm finished.

OK, I'm going to make a stab at describing the Apple "bug" that causes this bug's crashes. It's actually a design flaw, and is built deeply into macOS (and probably most/all other modern OSes). The problem is that run loops can be nested. And if things happen just right (or wrong), a nested run loop can destroy resources being used in the run loop it's nested on top of, leading to UAF crashes in the "lower" run loop.

As best I can tell there's no general fix. The problem needs to be addressed on a case-by-case basis, whenever it shows up. You need to find the resource that's triggering the crashes, and retain it before nesting a run loop that might destroy it. (It can be released after the nested run loop finishes.)

You might say that you should avoid nesting run loops. But that's not feasible. It's benefits far outweigh its disadvantages. For example, a modal run loop (using in dragging, let's say) might freeze up your app if you can't periodically nest other run loops on top of it.

In this bug's case, the way to address the problem is my patch from comment #72. The resource that's being destroyed in a "rogue" nested run loop is the (native) main window. The workaround is to hold a reference to this native window until its Mozilla counterpart (and owner) is destroyed -- until the nsCocoaWindow destructor is called.

It's just luck that Safari doesn't crash. It's not that Apple was aware of these crashes and secretly worked around them. It just happens to hold a reference to the main window long enough to prevent them from happening.

Chromium (and Google Chrome) crashes on accessing not the main window itself, but one of its NSView components (`WebContentsViewCocoa`). It, too, already holds a reference to the main window. But not, apparently, to all of its components.

Mozilla's apps (Firefox and Thunderbird) do crash on macOS 13 (and presumably also on lower versions), but with much lower frequency than on macOS 14 and 15. I'm not sure why. Chrome, as best I can tell, crashes with equal frequency on macOS 14 and 13. Google, of course, doesn't publish its crash stats. But my hook library "works" on Chrome just as easily on macOS 13 as on macOS 14.

My hook library deliberately nests a "rogue" run loop -- one that closes and destroys the main window. I'm still working on it. But I'll post it when I'm finished.