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 <[email protected]> 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 > >
_______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
