[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGABRT and SIGV in libobjc2
|
From: |
David Chisnall |
|
Subject: |
Re: SIGABRT and SIGV in libobjc2 |
|
Date: |
Wed, 6 Dec 2017 17:17:55 +0000 |
On 6 Dec 2017, at 13:46, Andreas Fink <afink@list.fink.org> wrote:
>
> Hello folks,
>
> I have a heavily multithreaded application which produces two different
> crashes in libobjc2 code now.
> I believe I have hit a race condition.
>
> Here is the firs thread at SIGABRT:
>
>
> * frame #0: 0x00007ffff6f701be
> libobjc.so.4.6`objc_storeWeak(addr=0x00007fff7be0d628,
> obj=0x0000000000d32620) + 958 at arc.m:602
>
> Thread #27
>
> lldb) * thread #27: tid = 22581, 0x00007ffff6f701be
> libobjc.so.4.6`objc_storeWeak(addr=0x00007fff7be0d628,
> obj=0x0000000000d32620) + 958 at arc.m:602, name = 'tcap-task-queue'
> frame #0: 0x00007ffff6f701be
> libobjc.so.4.6`objc_storeWeak(addr=0x00007fff7be0d628,
> obj=0x0000000000d32620) + 958 at arc.m:602
> 599 {
> 600 for (int i=0 ; i<4 ; i++)
> 601 {
> -> 602 if (0 == ref->ref[i])
> 603 {
> 604 ref->ref[i] = addr;
> 605 *addr = obj;
>
>
> Thread #26
>
> * thread #26: tid = 22580, 0x00007fffefd46fcf libc.so.6`gsignal + 207, name
> = 'tcap-task-queue', stop reason = signal SIGABRT
> frame #0: 0x00007fffefd46fcf libc.so.6`gsignal + 207
> frame #1: 0x00007fffefd483fa libc.so.6`abort + 362
> frame #2: 0x00007fffefd84bd0
> libc.so.6`___lldb_unnamed_symbol235$$libc.so.6 + 704
> frame #3: 0x00007fffefd8af96
> libc.so.6`___lldb_unnamed_symbol294$$libc.so.6 + 166
> frame #4: 0x00007fffefd8c091
> libc.so.6`___lldb_unnamed_symbol299$$libc.so.6 + 2513
> frame #5: 0x00007ffff78c0f49
> libgnustep-base.so.1.25`default_free(zone=0x00007ffff7d7c608,
> ptr=0x00007fff288f7270) + 25 at NSZone.m:150
> frame #6: 0x00007ffff78c0d66
> libgnustep-base.so.1.25`NSZoneFree(zone=0x00007ffff7d7c608,
> ptr=0x00007fff288f7270) + 54 at NSZone.m:1792
> frame #7: 0x00007ffff77dd5ec
> libgnustep-base.so.1.25`NSDeallocateObject(anObject=0x00007fff288f7280) + 236
> at NSObject.m:705
> frame #8: 0x00007ffff77ddd4c libgnustep-base.so.1.25`-[NSObject
> dealloc](self=0x00007fff288f7280, _cmd="\x11") + 28 at NSObject.m:1195
> frame #9: 0x00007ffff6f6f7f1
> libobjc.so.4.6`release(obj=0x00007fff288f7280) + 225 at arc.m:212
> frame #10: 0x00007ffff6f6fb98
> libobjc.so.4.6`objc_release(obj=0x00007fff288f7280) + 40 at arc.m:454
>
> (lldb) up
> frame #5: 0x00007ffff78c0f49
> libgnustep-base.so.1.25`default_free(zone=0x00007ffff7d7c608,
> ptr=0x00007fff288f7270) + 25 at NSZone.m:150
> 147 static void
> 148 default_free (NSZone *zone, void *ptr)
> 149 {
> -> 150 free(ptr);
> 151 }
> 152
> 153 static void
> (lldb) up
> frame #6: 0x00007ffff78c0d66
> libgnustep-base.so.1.25`NSZoneFree(zone=0x00007ffff7d7c608,
> ptr=0x00007fff288f7270) + 54 at NSZone.m:1792
> 1789 {
> 1790 if (!zone)
> 1791 zone = NSDefaultMallocZone();
> -> 1792 (zone->free)(zone, ptr);
> 1793 }
> 1794
> 1795 BOOL
> (lldb) up
> frame #7: 0x00007ffff77dd5ec
> libgnustep-base.so.1.25`NSDeallocateObject(anObject=0x00007fff288f7280) + 236
> at NSObject.m:705
> 702 else
> 703 {
> 704 object_setClass((id)anObject,
> (Class)(void*)0xdeadface);
> -> 705 NSZoneFree(z, o);
> 706 }
> 707 }
> 708 return;
> (lldb) up
> frame #8: 0x00007ffff77ddd4c libgnustep-base.so.1.25`-[NSObject
> dealloc](self=0x00007fff288f7280, _cmd="\x11") + 28 at NSObject.m:1195
> 1192 */
> 1193 - (void) dealloc
> 1194 {
> -> 1195 NSDeallocateObject (self);
> 1196 }
> 1197
> 1198 - (void) finalize
>
>
>
> Also I saw a SIGSEGV crash where it points to a an object at address
> 0xDEADFB0E. (offset to 0xDEADBEEF?)
>
> Anyone having a hint what I'm seeing here?
It looks as if your deallocator is not calling the runtime function that
synchronises with weak references. I don’t know if anyone has ever tested the
zombie object stuff with ARC, so it’s probably broken.
David