Bugzilla

(In reply to Steven Michaud [:smichaud] (Retired) from comment #90)
> (In reply to Haik Aftandilian [:haik] from comment #89)
> > We haven't reported this to Apple yet because we didn't have a clear root cause / explanation. Do we have that now? Is there a particular nested run loop occurrence in Apple code we could point to? Thanks for the continued debugging, Steven.
> 
> I asked you to report this to Apple when I thought it was an Apple bug. Now I think this kind of crash is something inherent to run loop nesting, and that there's nothing Apple can (or should) do about it. I can't prove it, but I suspect it's impossible to come up with a general/universal solution. App developers need to seek solutions on a case-by-case basis, which will be different according to the different designs of their apps' event handling.
> 
> So I'd vote against opening a bug on this with Apple.

I'd like to back off from this, a bit. I still doubt it's possible to build a faultless run loop nesting system from first principles. But there may be an Apple bug here, after all.

These crashes *aren't* generic -- as you'd expect them to be if the problem was just difficulties with run loop nesting. They happen in a very specific place -- after the call to `-[NSArray enumerateObjectsWithOptions:usingBlock:]` from `-[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:]` whose block's invoke method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. Also, the crashes only happen when `_updateActiveTrackingAreasForWindowLocation` is called from `__58-[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke(block_literal *block)`. Normally they aren't called from a block invoke method.

All I'm certain about is this and the fact that this crashes involve a window being close in a nested run loop. I can't get much further without being able to reproduce the crashes (which will never happen). Apple probably won't be able to reproduce them, either. But they have access to the source code for where the crashes take place, which may include interesting developer comments. They also have access to their internal bug base and crash report base. They may be able to find relevant bugs in their code, or at least a way to work around these crashes specifically.

So yes, do report these crashes to Apple if you think that's appropriate. You'll need to quote liberally from my comments. If you want, I can actually write the report myself and post it here, for you to send to Apple.

By the way, I already showed (in comment #47 above) that these crashes aren't caused by deleting a window on a secondary thread.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #90)
> (In reply to Haik Aftandilian [:haik] from comment #89)
> > We haven't reported this to Apple yet because we didn't have a clear root cause / explanation. Do we have that now? Is there a particular nested run loop occurrence in Apple code we could point to? Thanks for the continued debugging, Steven.
> 
> I asked you to report this to Apple when I thought it was an Apple bug. Now I think this kind of crash is something inherent to run loop nesting, and that there's nothing Apple can (or should) do about it. I can't prove it, but I suspect it's impossible to come up with a general/universal solution. App developers need to seek solutions on a case-by-case basis, which will be different according to the different designs of their apps' event handling.
> 
> So I'd vote against opening a bug on this with Apple.

I'd like to back off from this, a bit. I still doubt it's possible to build a faultless run loop nesting system from first principles. But there may be an Apple bug here, after all.

These crashes *aren't* generic -- as you'd expect them to be if the problem was just difficulties with run loop nesting. They happen in a very specific place -- after the call to `-[NSArray enumerateObjectsWithOptions:usingBlock:]` from `-[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:]` whose block's invoke method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. Also, the crashes only happen when `_updateActiveTrackingAreasForWindowLocation` is called from `__58-[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke(block_literal *block)`. Normally they aren't called from a block invoke method.

All I'm certain about is this and the fact that this crashes involve a window being closed in a nested run loop. I can't get much further without being able to reproduce the crashes (which will never happen). Apple probably won't be able to reproduce them, either. But they have access to the source code for where the crashes take place, which may include interesting developer comments. They also have access to their internal bug base and crash report base. They may be able to find relevant bugs in their code, or at least a way to work around these crashes specifically.

So yes, do report these crashes to Apple if you think that's appropriate. You'll need to quote liberally from my comments. If you want, I can actually write the report myself and post it here, for you to send to Apple.

By the way, I already showed (in comment #47 above) that these crashes aren't caused by deleting a window on a secondary thread.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #90)
> (In reply to Haik Aftandilian [:haik] from comment #89)
> > We haven't reported this to Apple yet because we didn't have a clear root cause / explanation. Do we have that now? Is there a particular nested run loop occurrence in Apple code we could point to? Thanks for the continued debugging, Steven.
> 
> I asked you to report this to Apple when I thought it was an Apple bug. Now I think this kind of crash is something inherent to run loop nesting, and that there's nothing Apple can (or should) do about it. I can't prove it, but I suspect it's impossible to come up with a general/universal solution. App developers need to seek solutions on a case-by-case basis, which will be different according to the different designs of their apps' event handling.
> 
> So I'd vote against opening a bug on this with Apple.

I'd like to back off from this, a bit. I still doubt it's possible to build a faultless run loop nesting system from first principles. But there may be an Apple bug here, after all.

These crashes *aren't* generic -- as you'd expect them to be if the problem was just difficulties with run loop nesting. They happen in a very specific place -- after the call to `-[NSArray enumerateObjectsWithOptions:usingBlock:]` from `-[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:]` whose block's invoke method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. Also, the crashes only happen when `_updateActiveTrackingAreasForWindowLocation` is called from `__58-[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke(block_literal *block)`. Normally it isn't called from a block invoke method.

All I'm certain about is this and the fact that this crashes involve a window being closed in a nested run loop. I can't get much further without being able to reproduce the crashes (which will never happen). Apple probably won't be able to reproduce them, either. But they have access to the source code for where the crashes take place, which may include interesting developer comments. They also have access to their internal bug base and crash report base. They may be able to find relevant bugs in their code, or at least a way to work around these crashes specifically.

So yes, do report these crashes to Apple if you think that's appropriate. You'll need to quote liberally from my comments. If you want, I can actually write the report myself and post it here, for you to send to Apple.

By the way, I already showed (in comment #47 above) that these crashes aren't caused by deleting a window on a secondary thread.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #90)
> (In reply to Haik Aftandilian [:haik] from comment #89)
> > We haven't reported this to Apple yet because we didn't have a clear root cause / explanation. Do we have that now? Is there a particular nested run loop occurrence in Apple code we could point to? Thanks for the continued debugging, Steven.
> 
> I asked you to report this to Apple when I thought it was an Apple bug. Now I think this kind of crash is something inherent to run loop nesting, and that there's nothing Apple can (or should) do about it. I can't prove it, but I suspect it's impossible to come up with a general/universal solution. App developers need to seek solutions on a case-by-case basis, which will be different according to the different designs of their apps' event handling.
> 
> So I'd vote against opening a bug on this with Apple.

I'd like to back off from this, a bit. I still doubt it's possible to build a faultless run loop nesting system from first principles. But there may be an Apple bug here, after all.

These crashes *aren't* generic -- as you'd expect them to be if the problem was just difficulties with run loop nesting. They happen in a very specific place -- after the call to `-[NSArray enumerateObjectsWithOptions:usingBlock:]` from `-[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:]` whose block's invoke method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. Also, the crashes only happen when `_updateActiveTrackingAreasForWindowLocation` is called from `__58-[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke(block_literal *block)`. Normally it isn't called from a block invoke method.

All I'm certain about is this and the fact that these crashes involve a window being closed in a nested run loop. I can't get much further without being able to reproduce the crashes (which will never happen). Apple probably won't be able to reproduce them, either. But they have access to the source code for where the crashes take place, which may include interesting developer comments. They also have access to their internal bug base and crash report base. They may be able to find relevant bugs in their code, or at least a way to work around these crashes specifically.

So yes, do report these crashes to Apple if you think that's appropriate. You'll need to quote liberally from my comments. If you want, I can actually write the report myself and post it here, for you to send to Apple.

By the way, I already showed (in comment #47 above) that these crashes aren't caused by deleting a window on a secondary thread.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #90)
> (In reply to Haik Aftandilian [:haik] from comment #89)
> > We haven't reported this to Apple yet because we didn't have a clear root cause / explanation. Do we have that now? Is there a particular nested run loop occurrence in Apple code we could point to? Thanks for the continued debugging, Steven.
> 
> I asked you to report this to Apple when I thought it was an Apple bug. Now I think this kind of crash is something inherent to run loop nesting, and that there's nothing Apple can (or should) do about it. I can't prove it, but I suspect it's impossible to come up with a general/universal solution. App developers need to seek solutions on a case-by-case basis, which will be different according to the different designs of their apps' event handling.
> 
> So I'd vote against opening a bug on this with Apple.

I'd like to back off from this, a bit. I still doubt it's possible to build a faultless run loop nesting system from first principles. But there may be an Apple bug here, after all. Or at least something for Apple to do.

These crashes *aren't* generic -- as you'd expect them to be if the problem was just difficulties with run loop nesting. They happen in a very specific place -- after the call to `-[NSArray enumerateObjectsWithOptions:usingBlock:]` from `-[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:]` whose block's invoke method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. Also, the crashes only happen when `_updateActiveTrackingAreasForWindowLocation` is called from `__58-[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke(block_literal *block)`. Normally it isn't called from a block invoke method.

All I'm certain about is this and the fact that these crashes involve a window being closed in a nested run loop. I can't get much further without being able to reproduce the crashes (which will never happen). Apple probably won't be able to reproduce them, either. But they have access to the source code for where the crashes take place, which may include interesting developer comments. They also have access to their internal bug base and crash report base. They may be able to find relevant bugs in their code, or at least a way to work around these crashes specifically.

So yes, do report these crashes to Apple if you think that's appropriate. You'll need to quote liberally from my comments. If you want, I can actually write the report myself and post it here, for you to send to Apple.

By the way, I already showed (in comment #47 above) that these crashes aren't caused by deleting a window on a secondary thread.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #90)
> (In reply to Haik Aftandilian [:haik] from comment #89)
> > We haven't reported this to Apple yet because we didn't have a clear root cause / explanation. Do we have that now? Is there a particular nested run loop occurrence in Apple code we could point to? Thanks for the continued debugging, Steven.
> 
> I asked you to report this to Apple when I thought it was an Apple bug. Now I think this kind of crash is something inherent to run loop nesting, and that there's nothing Apple can (or should) do about it. I can't prove it, but I suspect it's impossible to come up with a general/universal solution. App developers need to seek solutions on a case-by-case basis, which will be different according to the different designs of their apps' event handling.
> 
> So I'd vote against opening a bug on this with Apple.

I'd like to back off from this, a bit. I still doubt it's possible to build a faultless run loop nesting system from first principles. But there may be an Apple bug here, after all. Or at least something for Apple to do.

These crashes *aren't* generic -- as you'd expect them to be if the problem was just difficulties with run loop nesting. They happen in a very specific place -- after the call to `-[NSArray enumerateObjectsWithOptions:usingBlock:]` from `-[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:]`, whose block's invoke method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. Also, the crashes only happen when `_updateActiveTrackingAreasForWindowLocation` is called from `__58-[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke(block_literal *block)`. Normally it isn't called from a block invoke method.

All I'm certain about is this and the fact that these crashes involve a window being closed in a nested run loop. I can't get much further without being able to reproduce the crashes (which will never happen). Apple probably won't be able to reproduce them, either. But they have access to the source code for where the crashes take place, which may include interesting developer comments. They also have access to their internal bug base and crash report base. They may be able to find relevant bugs in their code, or at least a way to work around these crashes specifically.

So yes, do report these crashes to Apple if you think that's appropriate. You'll need to quote liberally from my comments. If you want, I can actually write the report myself and post it here, for you to send to Apple.

By the way, I already showed (in comment #47 above) that these crashes aren't caused by deleting a window on a secondary thread.