[bug #59204] NSOperationQueue leak

Larry Campbell <[email protected]>
Newsgroups gmane.comp.lib.gnustep.bugs
Message-ID <[email protected]>
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 (;;)
    {
      /* We use a pool for each operation in case releasing the operation     
                                                     
       * causes it to be deallocated, and the deallocation of the operation   
                                                     
       * autoreleases something which needs to be cleaned up.                 
                                                     
       */
      ENTER_POOL
      NSOperation       *op;
      NSDate            *when;
      BOOL              found;

      when = [[NSDate alloc] initWithTimeIntervalSinceNow: 5.0];
      found = [internal->cond lockWhenCondition: 1 beforeDate: when];
      RELEASE(when);
      if (NO == found)
        {
          break;        // Idle for 5 seconds ... exit thread.                
                                                     
        }


ENTER_POOL is a macro that expands to:

#define ENTER_POOL                      @autoreleasepool{do{

This is *extremely dangerous!*  The 'break' above in thread breaks from the do
loop started by ENTER_POOL, not from the for(;;) loop in _thread, which is
what was obviously intended, and what the code did before the ENTER_POOL was
added in commit 41badcb417.

I really don't understand why ENTER_POOl isn't defined as

#define ENTER_POOL                      @autoreleasepool{do{

and LEAVE_POOL as 

#define LEAVE_POOL                      }

This is safer, does not hijack 'break' and 'continue' statements between them,
and everything compiles fine this way (except for Tools/AGSHtml.m, which is
clearly confused about its break statement at line 1087).



    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59204>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.