bug-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #33392] Multi-thread bug in NSObject retain and release


From: Jonathan Olson
Subject: [bug #33392] Multi-thread bug in NSObject retain and release
Date: Tue, 24 May 2011 16:14:13 +0000
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.68 Safari/534.24

URL:
  <http://savannah.gnu.org/bugs/?33392>

                 Summary: Multi-thread bug in NSObject retain and release
                 Project: GNUstep
            Submitted by: jpolsonaz
            Submitted on: Tue 24 May 2011 04:14:12 PM GMT
                Category: Base/Foundation
                Severity: 3 - Normal
              Item Group: Bug
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any

    _______________________________________________________

Details:

I have experienced frequent crashes in a heavily multi-threaded GNUstep
application.  All of these crashes indicate memory corruption, double frees,
etc.  I traced these crashes to the following atomic increment code in
NSObject.m which is NOT atomic at all.

static __inline__ int
GSAtomicIncrement(gsatomic_t X)
{
 __asm__ __volatile__ (
     "lock addl $1, %0"
     :"=m" (*X));
 return *X;
}

static __inline__ int
GSAtomicDecrement(gsatomic_t X)
{
 __asm__ __volatile__ (
     "lock subl $1, %0"
     :"=m" (*X));
 return *X;
}

Note that although the locked addl/subl instructions are atomic, the following
return *X results in a separate mov instruction.  If a context switch occurs
between these instructions, these functions can return incorrect values.

Later, NSObject uses the returned result from GSAtomicDecrement to determine
if the object must be deallocated.


      result =
GSAtomicDecrement((gsatomic_t)&(((obj)anObject)[-1].retained));
      if (result < 0)
         { /// deallocate object

If two threads simultaneously release the same object, it's possible for both
threads to invoke dealloc.

To work around this issue, I rebuilt GNUstep to use the slower NSLock rather
than the atomic increment/decrement instructions which eliminated these
crashes.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?33392>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]