I'll file a bug report with Debian later today, maybe that will get
the maintainer(s) to pull in new GNUstep release once it becomes
available.
Regards,
Ivan Vučica
via phone
On 16. vel. 2011., at 05:07, Jason Felice <[email protected]>
wrote:
gnustep-base-0.21.0 is deallocing lock classes which were
permanently registered in the libobjc's hash table.
I think the only option for ObjectiveC 2.0 right now is to use SVN
trunk. I'll try in the next couple days.
On Tue, Feb 15, 2011 at 8:49 PM, Jason Felice <[email protected]
> wrote:
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]> wro
te:
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
