Hi David, That makes sense to me, but I have to ask undefined based on what? The most recent "Objective-C Programming Language" I found didn't say anything on the subject. (Chapter 11 Threading.) I'll change the code here but was hoping to point out something to the other engineers as to why that's a bad idea and not to do it in the future.
Now I just need to come up with a failing test that shows our other major issue, class_getProperty not returning a property that's clearly in the class. On Thu, Jul 18, 2013 at 2:06 AM, David Chisnall <[email protected]> wrote: > 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 <[email protected]> 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 > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > > > > -- Sent from my STANTEC-ZEBRA > >
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
