Re: crashing in __objc_resolve_class_links (related to @synchonize implementation)

[Gregory Casamento]

Hey Guys,

I worked with Doug on this a bit.... replacing sync.m with my old
implementation solves the problem, but given that my implementation is
O(n) (where n is the number of objects being @synchonized) and David's
is O(1) I would like to fix David's implementation to deal with this
problem.

I'm not sure why it's crashing here.

Any thoughts?

GC

On Tue, Aug 3, 2010 at 2:52 PM, Doug Simons <address@hidden> wrote:
> I recently updated to the tip of the trunk (r31073) and am now getting at 
> least 2 different crashes in __objc_resolve_class_links as shown in the 
> backtraces below (on Ubuntu 8.04). I've rebuilt everything in case something 
> was out of sync. Does anyone have an idea what might be going on here?
>
> Eggplant: /build/buildd/gcc-4.2-4.2.4/src/libobjc/class.c:561: 
> __objc_resolve_class_links: Assertion 
> `((class1->class_pointer)&&((((class1->class_pointer)->info)&0x2L)==0x2L))' 
> failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb55feb90 (LWP 1670)]
> 0xb7f37410 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7f37410 in __kernel_vsyscall ()
> #1  0xb7280085 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2  0xb7281a01 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3  0xb727910e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
> #4  0xb73d31b1 in __objc_resolve_class_links () from /usr/lib/libobjc.so.2
> #5  0xb7a5f069 in objc_registerClassPair (cls=0x87da460) at runtime.c:991
> #6  0xb7a61055 in objc_sync_enter (obj=0x8b7ab58) at sync.m:77
>
> - - - - - - -
> Eggplant: /build/buildd/gcc-4.2-4.2.4/src/libobjc/class.c:560: 
> __objc_resolve_class_links: Assertion 
> `((class1)&&((((class1)->info)&0x1L)==0x1L))' failed.
>
> Program received signal SIGABRT, Aborted.
> [Switching to Thread 0xb41a7b90 (LWP 1686)]
> 0xb7f8c410 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xb7f8c410 in __kernel_vsyscall ()
> #1  0xb72d5085 in raise () from /lib/tls/i686/cmov/libc.so.6
> #2  0xb72d6a01 in abort () from /lib/tls/i686/cmov/libc.so.6
> #3  0xb72ce10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
> #4  0xb74281db in __objc_resolve_class_links () from /usr/lib/libobjc.so.2
> #5  0xb7aa28d7 in GSPrivateLoadModule (filename=0x8a71ef0, 
> errorStream=0xb73f5580,
>    loadCallback=0xb7950040 <_bundle_load_callback>, header=0x0, 
> debugFilename=0x0)
>    at objc-load.m:225
> #6  0xb794fc91 in -[NSBundle load] (self=0x89042a0, _cmd=0xb7b33e08)
>    at NSBundle.m:1588
> #7  0xb794cd74 in -[NSBundle principalClass] (self=0x89042a0, _cmd=0xb7eadcc0)
>    at NSBundle.m:1519
> #8  0xb7c7b92e in converter_bundles (format=0xb7f5a178, producer=1 '\001')
>    at NSAttributedString.m:158
> #9  0xb7c7bb7f in converter_class (format=0xb7f5a178, producer=6 '\006')
>    at NSAttributedString.m:210
> #10 0xb7c7fb3b in -[NSAttributedString(AppKit) 
> dataFromRange:documentAttributes:error:] (self=0x856c250, _cmd=0xb7eade78, 
> range={location = 0, length = 77},
>    dict=0x88547a8, error=0x0) at NSAttributedString.m:1016
> #11 0xb7c7a831 in -[NSAttributedString(AppKit) 
> RTFFromRange:documentAttributes:] (
>    self=0x856c250, _cmd=0x81c0530, range={location = 6, length = 77},
>    dict=0x88547a8) at NSAttributedString.m:947
>
>
> Thanks,
>
> Doug
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)