Re: Strange crash in __objc_resolve_class_links

[Jason Felice]

I'm using:

jason@jerry:~$ clang -v
clang version 2.8 (branches/release_28)
Target: x86_64-pc-linux-gnu
Thread model: posix

I get this error:
ZCPBXProjectReader_loads_plist_dictionary ... done
ZCPBXProjectReader_signals_error_if_plist_cant_be_loaded ... done
ZCPBXProjectReader_returns_error_message ... check_Zcode: class.c:561: __objc_resolve_class_links: Assertion `((class1->class_pointer)&&((((class1->class_pointer)->info)&0x2L)==0x2L))' failed.
Aborted
make[1]: *** [internal-check] Error 134

I'm using the gnustep-objc library, but I've gotten the same issue with both gcc-4.4 and gcc-4.5 libobjc.  Weird part:  If I run the _same build_ under the debugger, I get this output:

ZCPBXProjectReader_loads_plist_dictionary ... done
ZCPBXProjectReader_signals_error_if_plist_cant_be_loaded ... done
ZCPBXProjectReader_returns_error_message ... done
ZCPBXProjectReader_rejects_files_with_archiveVersion_ne_1 ... done
ZCPBXProjectReader_can_get_objects_hash ... check_Zcode: class.c:560: __objc_resolve_class_links: Assertion `((class1)&&((((class1)->info)&0x1L)==0x1L))' failed.

Program received signal SIGABRT, Aborted.

... which means it gets further, so we have some kind of uninitialized memory or race condition.

I haven't looked into it further yet.  Each test has it's own autorelease pool.

On Tue, Feb 15, 2011 at 4:34 PM, Ivan Vučica <ivucica@gmail.com> 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];

}

This is compiled with clang 1.1 under Debian:

ivucica@theevilmacbook:~/Development/Zcode/check$ clang -v

clang version 1.1 (Debian 2.7-3)

Target: i386-pc-linux-gnu

Thread model: posix

libobjc2 seems to be the one that shipped with GCC 4.4.5:

ivucica@theevilmacbook:~/Development/Zcode/check$ apt-cache showpkg libobjc2

Package: libobjc2

Versions: 

4.4.5-10 (/var/lib/apt/lists/ftp.hr.debian.org_debian_dists_testing_main_binary-i386_Packages) (/var/lib/dpkg/status)

(etc)

This is Objective-C 2.0 code. Tests are running consecutively one after another in the same process. Jason has experienced the same crash under Ubuntu. (I don't know the version 

What's wrong here? Is this a bug that's fixed in recent versions of the runtime or in recent versions of the GNUstep? Did we stumble upon some new bug? Did we forget to initialize anything? PBXProjLib uses just the Foundation. There appear to be no issues under Apple's Cocoa environment. 

Jason has done a bit of research on what is the issue, but I'd leave it to him to state the exact problems. In the meantime, the bug is reproducible, and I'm not sure what to do about it.

Any insight you guys could shed on this would be much appreciated. We'd (or at least I'd) hate to go back to ObjC1.0 just because of a silly bug. 

--
Regards,

Ivan Vučica