gnustep-dev
[Top][All Lists]
Advanced

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

Re: Crash with Clang 3.2 and @syncrhonize


From: David Chisnall
Subject: Re: Crash with Clang 3.2 and @syncrhonize
Date: Thu, 18 Jul 2013 10:06:07 +0100

This looks like expected behaviour.  @synchronise(nil) (which is what your code 
is doing via a somewhat convoluted path) is undefined behaviour.  It appears to 
work with recent versions of Apple libobjc, but it crashes with older versions. 
 Code that relies on it is fundamentally broken (what should it mean?  Don't 
acquire a lock at all, and potentially introduce races?  Acquire a global lock, 
and potentially introduce deadlock from unrelated bits of code holding the same 
lock?) and should be fixed.

David

On 18 Jul 2013, at 00:23, Doug Warren <address@hidden> wrote:

> I'm looking at an odd bug where very simple synchronize tests crash IE:
> @interface TestSync : NSObject
> @property(nonatomic, retain) NSString* sync;
> 
> - (BOOL) doSync;
> @end
> 
> @implementation TestSync
> 
> @synthesize sync;
> 
> - (BOOL) doSync
> {
>       @synchronized(sync)
>       {
>               BOOL bTest = YES;
>               return bTest;
>       }
> }
> 
> @end
> 
> TEST(objc_synchronized, sync)
> {
>     id localSync = [[TestSync alloc] init];
>     printf("Hi: %d\n", localSync->isa);
>     EXPECT_TRUE([localSync doSync]);
> }
> 
> Results in:
> [----------] 1 test from objc_synchronized
> [ RUN      ] objc_synchronized.sync
> Hi: 705172864
> Segmentation fault
> 
> With a stack trace of:
> ********** Crash dump: **********
> Build fingerprint: 'generic/sdk/generic:4.2.2/JB_MR1.1/576024:eng/test-keys'
> pid: 31728, tid: 31728, name: UNKNOWN  >>> /data/local/tmp/gtestnations <<<
> signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
> Stack frame #00  pc 0000c85c  /data/local/tmp/libobjc.so
> Stack frame #01  pc 0000d148  /data/local/tmp/libobjc.so (objc_sync_enter+64)
> Stack frame #02  pc 000234ac  /data/local/tmp/gtest
> Stack frame #03  pc 000236fc  /data/local/tmp/gtest
> 
> When looking at it under gdb, when referenceListForObject in associate.m is 
> called, object is NULL, and we're dereferencing NULL with the variable access 
> of isa.  Is there anyway to further debug what is going on from clang 
> converting @synthesize to the call to objc_sync_enter?
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev




-- Sent from my STANTEC-ZEBRA




reply via email to

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