Bugzilla

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(void *block, id obj, NSUInteger idx, BOOL *stop)`. This method calls out to a block. So why not, in the block, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's deallocator is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(void *block, id obj, NSUInteger idx, BOOL *stop)`. This `NSArray` method calls out to a block. So why not, in the block, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's deallocator is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(void *block, id obj, NSUInteger idx, BOOL *stop)`. This `NSArray` method calls out to a block. So why not, in the block, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's deconstructor is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(void *block, id obj, NSUInteger idx, BOOL *stop)`. This `NSArray` method calls out to a block. So why not, in the block, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's destructor is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock:]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(void *block, id obj, NSUInteger idx, BOOL *stop)`. This `NSArray` method calls out to a block. So why not, in the block, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's destructor is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock:]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. This `NSArray` method calls out to a block. So why not, in the block, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's destructor is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.

(Following up comment #86)

The external call nearest to these two crash locations (of any complexity) is one to`-[NSArray enumerateObjectsWithOptions:usingBlock:]` whose `block->invoke` method is `___collectTrackingAreasForTargetAndWinLoc_block_invoke(block_literal *block, id obj, NSUInteger idx, BOOL *stop)`. This `NSArray` method calls out to a block. So why not, after the block has returned, call out to another block that closes the main window? I did this, and it "worked". Including the results from both Firefox and Chromium, it reproduces this bug's crashes exactly. In Firefox the crashes happen on the call to `-[NSWindow windowNumber]`. In Chromium they happen on the call to `-[NSView trackingArea]`.

I won't go into detail about how I pulled this off. You can look at the source code for my hook library after I post it (which should be pretty soon now).

This told me what I already suspected -- that the solution is to postpone the main window's deallocation. If you look at my hook library's logging, you see that nsCocoaWindow's destructor is called quite "late". And in any case that's the last chance we have to intervene. So why not deallocate it there? And when I do that, my hook library's evil, `NSWindow` eating block no longer crashes Firefox.

I have to deal with the `HideWindowChrome` complication. But presuming I can, this still seems the best solution.