Re: Strange crash in __objc_resolve_class_links

[Richard Frith-Macdonald]

On 15 Feb 2011, at 21:34, Ivan Vučica wrote:

> Cheers,
> 
> on Zcode, Jason Felice has been doing great work on cleaning up the mess I 
> made of the code, refactoring it to make PBX reader actually usable in other 
> projects (separated into PBXProjLib), et cetera. The code can be pulled using 
> Mercurial with "hg clone https://bitbucket.org/ivucica/zcode"; (or viewed at 
> the same URL).
> 
> One of the things he's worked on is a test suite for PBXProjLib.  There's a 
> strange crash inside the runtime in one of the tests. Jason, please correct 
> me if anything I state below is wrong:
> 
> ivucica@theevilmacbook:~/Development/Zcode$ make check
> This is gnustep-make 2.4.0. Type 'make print-gnustep-make-help' for help.
> Making check in check ...
> for t in obj/check_Zcode; do $t || exit $?; done
> ZCPBXProjectReader_loads_plist_dictionary ... done
> ZCPBXProjectReader_signals_error_if_plist_cant_be_loaded ... done
> ZCPBXProjectReader_returns_error_message ... check_Zcode: 
> /scratch/packages/gcc/4.4/gcc-4.4-4.4.5/src/libobjc/class.c:560: 
> __objc_resolve_class_links: Assertion 
> `((class1->class_pointer)&&((((class1->class_pointer)->info)&0x2L)==0x2L))' 
> failed.
> Aborted
> make[1]: *** [internal-check] Error 134
> make: *** [internal-check] Error 2
> 
> 
> This is the code of the test:
> 
> CHECK(ZCPBXProjectReader_returns_error_message)
> {
>         ZCPBXProjectReader *r = [[ZCPBXProjectReader alloc] 
> initWithFile:@"does_not_exist.pbxproj"];
>         (void) r.plist;
>         assert(r.errorMessage != nil);
>         [r release];
> }

As far as I can see nobody has replied to this ... perhaps because there's 
really not much to go on as we don't know where things might be going wrong 
(crashes in the runtime library are usually caused by memory corruption for 
instance).

So, we could be looking at a problem caused earlier in the code, or something 
hidden in one of the methods called within this check.

Incidentally, when most of the GNustep maintainers met at FOSDEM this year, we 
decided to ban the use of the '.' operator for property access within GNUstep 
... it's pretty universally thought to encourage bad code by obscuring what's 
going on, and your example above is a case in point ... the '(void)r.plist;' 
would conventionally be thought of as a reference to an instance variable, and 
since the value is not used, many people would expect the compiler to simply 
optimise away that line of code completely.  You ought to use '(void) [r 
plist];' instead.
Similarly, 'r.errorMessage' obscures the fact that messaging is going on ... it 
ought to be [r errorMessage].

Finally, because the '.' syntax is deprecated (and someone at FOSDEM said it 
behaves differently in different versions of clang), it is certainly not well 
tested ... you might find that removing it makes the crash in your code go away 
as well as improving the code clarity.