[bug #59204] NSOperationQueue leak

Update of bug #59204 (project gnustep): Status: Ready For Test => Fixed Open/Closed: In Test => Closed ___ Follow-up Comment #15: No news since a

[bug #59204] NSOperationQueue leak

Follow-up Comment #14, bug #59204 (project gnustep): I changed the definition of the macros in trunk (and added some comments). I do worry that there might be code that's broken by the behavior change though (I found/fixed one place). ___

[bug #59204] NSOperationQueue leak

Follow-up Comment #13, bug #59204 (project gnustep): I think we all agree that the loop in the macros is more trouble than it's worth, and we should change it. > Since you often want to wrap the body of a loop in an > autorelease pool, hijacking break & continue is > particularly dangerous.

[bug #59204] NSOperationQueue leak

Follow-up Comment #12, bug #59204 (project gnustep): You are right, even in the non-ARC version of the macro the loop does more harm. I think it is there to allow the draining of the pool, but this does break the expected behaviour of the break statement. This means "break" and "return" will leak

[bug #59204] NSOperationQueue leak

Follow-up Comment #11, bug #59204 (project gnustep): I don't see why we need to support 'break' at all. In other words, I propose getting rid of the do/while loop in both cases. Since you often want to wrap the body of a loop in an autorelease pool, hijacking break & continue is particularly

[bug #59204] NSOperationQueue leak

Update of bug #59204 (project gnustep): Category:None => Base/Foundation Item Group:None => Bug Status:None => Ready For Test Assigned to:

[bug #59204] NSOperationQueue leak

Follow-up Comment #9, bug #59204 (project gnustep): I altered the retain/release change. The ENTER_POOL/LEAVE_POOL macros are presumably intended to marry the original retain/release mechanism with ARC semantics, and don't really work. I wonder if they are perhaps more of a danger than an

[bug #59204] NSOperationQueue leak

Follow-up Comment #8, bug #59204 (project gnustep): oops, pasted too fast; obviously I meant to suggest that ENTER_POOL should be just #define ENTER_POOL @autoreleasepool{ ___ Reply to this item at:

[bug #59204] NSOperationQueue leak

Follow-up Comment #7, bug #59204 (project gnustep): Actually the proposed fix creates (incidentally) a bug that causes NSOperation threads never to exit! -[NSOperationQueue _thread] (now) starts off like this (the ENTER_POOL/LEAVE_POOL were recently added as part of the fix here): for (;;)

[bug #59204] NSOperationQueue leak

Update of bug #59204 (project gnustep): Open/Closed:Open => Analyzed ___ Follow-up Comment #6: Having investigated, I think your problem is not a leak, but one of timing. Your testcase

[bug #59204] NSOperationQueue leak

Follow-up Comment #5, bug #59204 (project gnustep): Thanks ... given the comment of the commit, it looks like this was an entirely accidental change. ___ Reply to this item at:

[bug #59204] NSOperationQueue leak

Follow-up Comment #4, bug #59204 (project gnustep): Probably should restore the check for isCancelled, too. ___ Reply to this item at: ___ Message

[bug #59204] NSOperationQueue leak

Follow-up Comment #3, bug #59204 (project gnustep): Looks like this bug was added by this commit: commit 7380e850e4745282806e62320df5c016bfd4f31e Author: Richard Frith-Macdonald Date: Tue Dec 4 11:09:18 2018 + minor whitespace tidyups The relevant part of that commit is: @@

[bug #59204] NSOperationQueue leak

Follow-up Comment #2, bug #59204 (project gnustep): Another data point: the leak does NOT exist in gnustep-base 1.24.9. So it seems to have been introduced between 1.24.9 and 1.26.0. ___ Reply to this item at:

[bug #59204] NSOperationQueue leak

Follow-up Comment #1, bug #59204 (project gnustep): I discovered this in gnustep-base 1.27.0 but have verified that the leak also exists in gnustep-base 1.26.0. ___ Reply to this item at:

[bug #59204] NSOperationQueue leak

URL: Summary: NSOperationQueue leak Project: GNUstep Submitted by: lcampbel Submitted on: Tue 29 Sep 2020 12:39:15 PM UTC Category: None Severity: 3 - Normal