[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libobjc2 still failing tests
From: |
Andreas Fink |
Subject: |
Re: libobjc2 still failing tests |
Date: |
Sat, 26 Jan 2019 12:57:45 +0100 |
> On 26 Jan 2019, at 12:48, David Chisnall <gnustep@theravensnest.org> wrote:
>
> On 26 Jan 2019, at 11:35, Andreas Fink <afink@list.fink.org> wrote:
>>
>> ok removing the static in the test fixes the test.
>> But when I try to use it from gnustep-base, all tests are failing there.
>
> I was seeing an issue where all of the -base tests would fail if you didn’t
> run make install before running them. Not sure if it’s related?
>
> Do you have backtraces for any of the failing tests? I think Richard added a
> thing so that the tests are linked with a sensible rpath, so you can just run
> them directly in your favourite debugger.
>
> David
>
Yes I did make install
There are no backtraces anywhere. At least I dont know where to find it.
trying to reproduce it by hand:
# clang-8 `gnustep-config --objc-flags` `gnustep-config --objc-libs
--base-libs` example2.m
/tmp/example2-069785.o: In function `main':
/Users/afink/development/gnustep/make/example2.m:10: undefined reference to
`._OBJC_REF_CLASS_NSObject'
clang: error: linker command failed with exit code 1 (use -v to see invocation)
How can that be?
#gnustep-config --objc-flags
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNUSTEP_RUNTIME=1
-D_NONFRAGILE_ABI=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions
-fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN
-DGSDIAGNOSE -Wno-import -g -O2 -fobjc-runtime=gnustep-2.0 -fblocks
-fconstant-string-class=NSConstantString -I. -I/root/GNUstep/Library/Headers
-I/usr/local/include
#gnustep-config --objc-libs --base-libs
-rdynamic -pthread -fexceptions -fobjc-runtime=gnustep-2.0 -fblocks
-L/root/GNUstep/Library/Libraries -L/usr/local/lib -lpthread -lobjc -lm
# ls -lad /usr/local/lib/libobjc*
-rw-r--r-- 1 root staff 1109834 Jan 26 12:16 /usr/local/lib/libobjc.a
lrwxrwxrwx 1 root staff 14 Jan 16 10:54 /usr/local/lib/libobjc.so ->
libobjc.so.4.6
-rw-r--r-- 1 root staff 643240 Jan 26 12:16 /usr/local/lib/libobjc.so.4.6
# ls -lad /usr/local/lib/libgnustep-base.so*
lrwxrwxrwx 1 root staff 23 Jan 26 12:19 /usr/local/lib/libgnustep-base.so
-> libgnustep-base.so.1.26
lrwxrwxrwx 1 root staff 25 Jan 26 12:19
/usr/local/lib/libgnustep-base.so.1.26 -> libgnustep-base.so.1.26.0
-rwxr-xr-x 1 root staff 11342248 Jan 26 12:19
/usr/local/lib/libgnustep-base.so.1.26.0
This is from ./Tests/tests.log
Building in base/coding
Making all for test_tool basictypes...
Making all for test_tool decoding...
Compiling file basictypes.m ...
Compiling file decoding.m ...
basictypes.m:157:1: warning: using floating point absolute value function
'fabs' when argument is of integer type [-Wabsolute-value]
TEST_DECL(BOOL, BOOL);
^
basictypes.m:136:10: note: expanded from macro 'TEST_DECL'
PASS((VAL_TEST(*expect,*toDecode) && [str isEqual:str2]), \
^
basictypes.m:154:32: note: expanded from macro 'VAL_TEST'
#define VAL_TEST(testx, testy) EQ(testx,testy)
^
/usr/local/share/GNUstep/Makefiles/TestFramework/Testing.h:567:19: note:
expanded from macro 'EQ'
#define EQ(x, y) (fabs((x) - (y)) <= fabs((x) + (y)) * (FLT_EPSILON * 100))
^
basictypes.m:157:1: note: use function 'abs' instead
basictypes.m:136:10: note: expanded from macro 'TEST_DECL'
PASS((VAL_TEST(*expect,*toDecode) && [str isEqual:str2]), \
^
basictypes.m:154:32: note: expanded from macro 'VAL_TEST'
#define VAL_TEST(testx, testy) EQ(testx,testy)
^
/usr/local/share/GNUstep/Makefiles/TestFramework/Testing.h:567:19: note:
expanded from macro 'EQ'
#define EQ(x, y) (fabs((x) - (y)) <= fabs((x) + (y)) * (FLT_EPSILON * 100))
^
basictypes.m:157:1: warning: using floating point absolute value function
'fabs' when argument is of integer type [-Wabsolute-value]
TEST_DECL(BOOL, BOOL);
^
basictypes.m:136:10: note: expanded from macro 'TEST_DECL'
PASS((VAL_TEST(*expect,*toDecode) && [str isEqual:str2]), \
^
basictypes.m:154:32: note: expanded from macro 'VAL_TEST'
#define VAL_TEST(testx, testy) EQ(testx,testy)
^
/usr/local/share/GNUstep/Makefiles/TestFramework/Testing.h:567:38: note:
expanded from macro 'EQ'
#define EQ(x, y) (fabs((x) - (y)) <= fabs((x) + (y)) * (FLT_EPSILON * 100))
^
basictypes.m:157:1: note: use function 'abs' instead
basictypes.m:136:10: note: expanded from macro 'TEST_DECL'
PASS((VAL_TEST(*expect,*toDecode) && [str isEqual:str2]), \
^
basictypes.m:154:32: note: expanded from macro 'VAL_TEST'
#define VAL_TEST(testx, testy) EQ(testx,testy)
^
/usr/local/share/GNUstep/Makefiles/TestFramework/Testing.h:567:38: note:
expanded from macro 'EQ'
#define EQ(x, y) (fabs((x) - (y)) <= fabs((x) + (y)) * (FLT_EPSILON * 100))
^
Linking test_tool decoding ...
2 warnings generated.
Linking test_tool basictypes ...
Testing basictypes.m...
Running base/coding/basictypes.m...
/usr/local/bin/gnustep-tests: line 309: 28132 Segmentation fault $RUN_CMD
Failed file: basictypes.m aborted without running all tests!
and thats about it.... it repeats this for every test
lldb ./Tests/base/coding/obj/basictypes
(lldb) run
Process 28625 launched:
'/Users/afink/development/gnustep/base/Tests/base/coding/obj/basictypes'
(x86_64)
Process 28625 stopped
* thread #1, name = 'basictypes', stop reason = signal SIGSEGV: invalid address
(fault address: 0x7fffff7feffc)
frame #0: 0x00007ffff6a22d4e libc.so.6`_IO_vfprintf + 30
libc.so.6`_IO_vfprintf:
-> 0x7ffff6a22d4e <+30>: movl %eax, -0x4a4(%rbp)
0x7ffff6a22d54 <+36>: movl 0xc0(%rdi), %eax
0x7ffff6a22d5a <+42>: testl %eax, %eax
0x7ffff6a22d5c <+44>: jne 0x7ffff6a22e80 ; <+336>
(lldb) bt
* thread #1, name = 'basictypes', stop reason = signal SIGSEGV: invalid address
(fault address: 0x7fffff7feffc)
* frame #0: 0x00007ffff6a22d4e libc.so.6`_IO_vfprintf + 30
frame #1: 0x00007ffff6a4be89 libc.so.6`vsnprintf + 121
frame #2: 0x00007ffff6a2b2c2 libc.so.6`snprintf + 130
frame #3: 0x00007ffff79060f4 libgnustep-base.so.1.26`-[NSMethodSignature
_initWithObjCTypes:](self=0x000000000150d8f8, _cmd=<unavailable>,
t=<unavailable>) at NSMethodSignature.m:539:4
frame #4: 0x00007ffff7906241 libgnustep-base.so.1.26`+[NSMethodSignature
signatureWithObjCTypes:](self=<unavailable>, _cmd=<unavailable>,
t=<unavailable>) at NSMethodSignature.m:559:10
frame #5: 0x00007ffff79a7d4a
libgnustep-base.so.1.26`gs_objc_msg_forward2(receiver=0x00007ffff7d864f8,
sel="\xffffff90\n") at GSFFIInvocation.m:140:13
frame #6: 0x00007ffff72ae2c1 libobjc.so.4.6`slowMsgLookup at
sendmsg2.c:149:28
frame #7: 0x00007ffff72adf21
libobjc.so.4.6`slowMsgLookup(receiver=0x00007fffff7ffa70, cmd="\xffffff90\n")
at sendmsg2.c:161
frame #8: 0x00007ffff72b2084
libobjc.so.4.6`__objc_block_trampoline_end_sret at objc_msgSend.x86-64.S:285
frame #9: 0x00007ffff78d63a6 libgnustep-base.so.1.26`+[NSException
raise:format:arguments:](self=0x00007ffff7d68088, _cmd=<unavailable>,
name=0x00007ffff7db2e48, format=<unavailable>, argList=<unavailable>) at
NSException.m:1390:12
frame #10: 0x00007ffff78d6370 libgnustep-base.so.1.26`+[NSException
raise:format:](self=<unavailable>, _cmd=<unavailable>, name=<unavailable>,
format=<unavailable>) at NSException.m:1377:3
frame #11: 0x00007ffff7913d66 libgnustep-base.so.1.26`-[NSObject
doesNotRecognizeSelector:](self=<unavailable>, _cmd=<unavailable>,
aSelector="\xffffff90\n") at NSObject.m:1723:3
frame #12: 0x00007ffff79a8c66
libgnustep-base.so.1.26`GSFFIInvocationCallback(cif=0x000000000150d600,
retp=0x00007fffff7ffe90, args=0x00007fffff7ffcf0, user=0x000000000150d5b8) at
GSFFIInvocation.m:606:3
frame #13: 0x00007ffff54c1e2f libffi.so.6`ffi_closure_unix64_inner + 463
frame #14: 0x00007ffff54c21a0 libffi.so.6`ffi_closure_unix64 + 70
frame #15: 0x00007ffff78d63a6 libgnustep-base.so.1.26`+[NSException
raise:format:arguments:](self=0x00007ffff7d68088, _cmd=<unavailable>,
name=0x00007ffff7db2e48, format=<unavailable>, argList=<unavailable>) at
NSException.m:1390:12
frame #16: 0x00007ffff78d6370 libgnustep-base.so.1.26`+[NSException
raise:format:](self=<unavailable>, _cmd=<unavailable>, name=<unavailable>,
format=<unavailable>) at NSException.m:1377:3
frame #17: 0x00007ffff7913d66 libgnustep-base.so.1.26`-[NSObject
doesNotRecognizeSelector:](self=<unavailable>, _cmd=<unavailable>,
aSelector="\xffffff90\n") at NSObject.m:1723:3
frame #18: 0x00007ffff79a8c66
libgnustep-base.so.1.26`GSFFIInvocationCallback(cif=0x000000000150c090,
retp=0x00007fffff800200, args=0x00007fffff800060, user=0x000000000150c048) at
GSFFIInvocation.m:606:3
frame #19: 0x00007ffff54c1e2f libffi.so.6`ffi_closure_unix64_inner + 463
frame #20: 0x00007ffff54c21a0 libffi.so.6`ffi_closure_unix64 + 70
frame #21: 0x00007ffff78d63a6 libgnustep-base.so.1.26`+[NSException
raise:format:arguments:](self=0x00007ffff7d68088, _cmd=<unavailable>,
name=0x00007ffff7db2e48, format=<unavailable>, argList=<unavailable>) at
NSException.m:1390:12
frame #22: 0x00007ffff78d6370 libgnustep-base.so.1.26`+[NSException
raise:format:](self=<unavailable>, _cmd=<unavailable>, name=<unavailable>,
format=<unavailable>) at NSException.m:1377:3
frame #23: 0x00007ffff7913d66 libgnustep-base.so.1.26`-[NSObject
doesNotRecognizeSelector:](self=<unavailable>, _cmd=<unavailable>,
aSelector="\xffffff90\n") at NSObject.m:1723:3
frame #24: 0x00007ffff79a8c66
libgnustep-base.so.1.26`GSFFIInvocationCallback(cif=0x000000000150bac0,
retp=0x00007fffff800570, args=0x00007fffff8003d0, user=0x000000000150ba78) at
GSFFIInvocation.m:606:3
frame #25: 0x00007ffff54c1e2f libffi.so.6`ffi_closure_unix64_inner + 463
frame #26: 0x00007ffff54c21a0 libffi.so.6`ffi_closure_unix64 + 70
frame #27: 0x00007ffff78d63a6 libgnustep-base.so.1.26`+[NSException
raise:format:arguments:](self=0x00007ffff7d68088, _cmd=<unavailable>,
name=0x00007ffff7db2e48, format=<unavailable>, argList=<unavailable>) at
NSException.m:1390:12
.... a million time s the same....
ist=<unavailable>) at NSException.m:1390:12
frame #57148: 0x00007ffff78d6370 libgnustep-base.so.1.26`+[NSException
raise:format:](self=<unavailable>, _cmd=<unavailable>, name=<unavailable>,
format=<unavailable>) at NSException.m:1377:3
frame #57149: 0x00007ffff7913d66 libgnustep-base.so.1.26`-[NSObject
doesNotRecognizeSelector:](self=<unavailable>, _cmd=<unavailable>,
aSelector="\xffffff90\n") at NSObject.m:1723:3
frame #57150: 0x00007ffff79a8c66
libgnustep-base.so.1.26`GSFFIInvocationCallback(cif=0x000000000072c1c0,
retp=0x00007fffffffdde0, args=0x00007fffffffdc40, user=0x000000000072c178) at
GSFFIInvocation.m:606:3
frame #57151: 0x00007ffff54c1e2f libffi.so.6`ffi_closure_unix64_inner + 463
frame #57152: 0x00007ffff54c21a0 libffi.so.6`ffi_closure_unix64 + 70
frame #57153: 0x00007ffff78d63a6 libgnustep-base.so.1.26`+[NSException
raise:format:arguments:](self=0x00007ffff7d68088, _cmd=<unavailable>,
name=0x00007ffff7db2e48, format=<unavailable>, argList=<unavailable>) at
NSException.m:1390:12
frame #57154: 0x00007ffff78d6370 libgnustep-base.so.1.26`+[NSException
raise:format:](self=<unavailable>, _cmd=<unavailable>, name=<unavailable>,
format=<unavailable>) at NSException.m:1377:3
frame #57155: 0x00007ffff7913d66 libgnustep-base.so.1.26`-[NSObject
doesNotRecognizeSelector:](self=<unavailable>, _cmd=<unavailable>,
aSelector="\xffffffe5") at NSObject.m:1723:3
frame #57156: 0x00007ffff79a8c66
libgnustep-base.so.1.26`GSFFIInvocationCallback(cif=0x00000000007199b0,
retp=0x00007fffffffe150, args=0x00007fffffffdfb0, user=0x0000000000719968) at
GSFFIInvocation.m:606:3
frame #57157: 0x00007ffff54c1e2f libffi.so.6`ffi_closure_unix64_inner + 463
frame #57158: 0x00007ffff54c21a0 libffi.so.6`ffi_closure_unix64 + 70
frame #57159: 0x00007ffff78980d7 libgnustep-base.so.1.26`+[NSCharacterSet
_staticSet:length:number:](self=<unavailable>, _cmd=<unavailable>,
bytes=0x00007ffff7a78210, length=<unavailable>, number=7) at
NSCharacterSet.m:675:8
frame #57160: 0x00007ffff795378b libgnustep-base.so.1.26`+[NSString
initialize](self=0x00007ffff7d864f8, _cmd=<unavailable>) at NSString.m:827:17
frame #57161: 0x00007ffff72a6e6e
libobjc.so.4.6`objc_send_initialize(object=<unavailable>) at dtable.c:783:2
frame #57162: 0x00007ffff72ae077 libobjc.so.4.6`slowMsgLookup at
sendmsg2.c:107:4
frame #57163: 0x00007ffff72adf21
libobjc.so.4.6`slowMsgLookup(receiver=0x00007fffffffe2b0, cmd="b\x0f") at
sendmsg2.c:161
frame #57164: 0x00007ffff72b2084
libobjc.so.4.6`__objc_block_trampoline_end_sret at objc_msgSend.x86-64.S:285
frame #57165: 0x00007ffff7913650 libgnustep-base.so.1.26`+[NSObject
initialize](self=0x00007ffff7d79b08, _cmd=<unavailable>) at NSObject.m:1082:31
frame #57166: 0x00007ffff72a6e6e
libobjc.so.4.6`objc_send_initialize(object=<unavailable>) at dtable.c:783:2
frame #57167: 0x00007ffff72a6ca5
libobjc.so.4.6`objc_send_initialize(object=<unavailable>) at dtable.c:678:3
frame #57168: 0x00007ffff72ae077 libobjc.so.4.6`slowMsgLookup at
sendmsg2.c:107:4
frame #57169: 0x00007ffff72adf21
libobjc.so.4.6`slowMsgLookup(receiver=0x00007fffffffe590, cmd="d") at
sendmsg2.c:161
frame #57170: 0x00007ffff72b2084
libobjc.so.4.6`__objc_block_trampoline_end_sret at objc_msgSend.x86-64.S:285
frame #57171: 0x000000000040b382 basictypes`main at basictypes.m:161:29
frame #57172: 0x00007ffff69fc2e1 libc.so.6`__libc_start_main + 241
frame #57173: 0x000000000040178a basictypes`_start + 42
(lldb)
> On 26 Jan 2019, at 12:35, Andreas Fink <afink@list.fink.org> wrote:
>
> ok removing the static in the test fixes the test.
> But when I try to use it from gnustep-base, all tests are failing there.
>
> Even in gnustep make when I run gnustep-test . it fails at the most simple
> things
>
>
>
> Building in ./TestFramework
> This is gnustep-make 2.7.0. Type 'make print-gnustep-make-help' for help.
> Running in gnustep-make version 2 strict mode.
> Making all for test_tool example1...
> Making all for test_tool example2...
> Making all for test_tool example3...
> Making all for test_tool example4...
> Compiling file example1.m ...
> Compiling file example4.m ...
> Compiling file example2.m ...
> Compiling file example3.m ...
> Linking test_tool example1 ...
> Linking test_tool example4 ...
> Linking test_tool example2 ...
> Linking test_tool example3 ...
> Making all for test_tool example5...
> Compiling file example5.m ...
> Making all for test_tool example6...
> Making all for test_tool example7...
> Making all for test_tool example8...
> Compiling file example6.m ...
> Compiling file example7.m ...
> Compiling file example8.m ...
> Linking test_tool example5 ...
> Linking test_tool example8 ...
> Linking test_tool example6 ...
> Linking test_tool example7 ...
> Making all for test_tool example9...
> Compiling file example9.m ...
> Linking test_tool example9 ...
>
> Testing example1.m...
> Running ./TestFramework/example1.m...
> Passed test: integer equality works
> Completed file: example1.m
>
> Testing example2.m...
> Running ./TestFramework/example2.m...
> /usr/local/bin/gnustep-tests: line 309: 6828 Segmentation fault $RUN_CMD
> Failed file: example2.m aborted without running all tests!
>
> Testing example3.m...
> Running ./TestFramework/example3.m...
> /usr/local/bin/gnustep-tests: line 309: 6850 Segmentation fault $RUN_CMD
> Failed file: example3.m aborted without running all tests!
>
>
>
> This is example1 which passes:
>
>
> #import "Testing.h"
>
> /* This is the absolute minimal test program ...
> * a single test case involving plain C and no Objective-C code.
> *
> * If you run the test with 'gnustep-tests example1.m' it should
> * report a single test pass
> */
> int
> main()
> {
> /* This is too simple to really be useful, but it's a start.
> */
> pass(1 == 1, "integer equality works");
> return 0;
> }
>
>
>
> This is example2 which fails:
>
> #import "Testing.h"
>
> /* A second test ... your first go at testing with ObjectiveC
> *
> * If you run the test with 'gnustep-tests example2.m' it should
> * report two test passes.
> */
> int
> main()
> {
> /* We start a set here ...
> * Having a set means we do not need to bother creating an autorelease pool.
> */
> START_SET("example set")
>
> pass(1 == 1, "integer equality works");
> pass([[NSObject new] autorelease] != nil, "+new creates an object");
>
> END_SET("example set")
>
> return 0;
> }
>
>
> my gnustep make config line looks like this:
>
> export RUNTIME_VERSION=gnustep-2.0
> #export LDLAGS="-L/usr/local/lib"
> ./configure \
> --with-layout=fhs \
> --disable-importing-config-file \
> --enable-native-objc-exceptions \
> --enable-objc-arc \
> --enable-install-ld-so-conf \
> --with-library-combo=ng-gnu-gnu \
> --with-config-file=/usr/local/etc/GNUstep/GNUstep.conf \
> --with-user-config-file='.GNUstep.conf' \
> --with-user-defaults-dir='GNUstep/Library/Defaults' \
> #--with-objc-lib-flag="-l:libobjc.so.4.6"
>
>
> I can't seem to be able to print out how the tests are compiled so I can not
> even manually reproduce the "bug".
> The odd thing is its not a building issue but a runtime crash of a simple
> test which is totally confusing..
>
>
>> On 25 Jan 2019, at 18:07, David Chisnall <gnustep@theravensnest.org> wrote:
>>
>> On 25/01/2019 16:46, Andreas Fink wrote:
>>> 17/162 Test #17: AssociatedObject ..................................
>>> Passed 0.00 sec
>>> Start 18: AssociatedObject_optimised
>>> 18/162 Test #18: AssociatedObject_optimised
>>> ........................***Exception: Other 0.00 sec
>>> Start 19: AssociatedObject_legacy
>>> 19/162 Test #19: AssociatedObject_legacy ...........................
>>> Passed 0.00 sec
>>> Start 20: AssociatedObject_legacy_optimised
>>> 20/162 Test #20: AssociatedObject_legacy_optimised
>>> .................***Exception: Other 0.00 sec
>>> this still fails with clang-8
>>
>> This one seems to be a clang bug. Inserting a printf in the -dealloc
>> method, it *is* being called and is storing the true value in the global,
>> but clang is optimising this away. This bug doesn't appear in the FreeBSD
>> packaged version of LLVM 8, so it's probably recent breakage. I'll try to
>> put together a reduced test case.
>>
>> Removing static from the declaration of deallocCalled fixes the test.
>>
>> David
>
>
>
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep
- Re: libobjc2 still failing tests, (continued)
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/25
- Re: libobjc2 still failing tests, Andreas Fink, 2019/01/25
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/25
- Re: libobjc2 still failing tests, Jordan Schidlowsky, 2019/01/25
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/25
- Re: libobjc2 still failing tests, Jordan Schidlowsky, 2019/01/25
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/26
- libobjc2 AArch64, Jordan Schidlowsky, 2019/01/26
- Re: libobjc2 still failing tests, Andreas Fink, 2019/01/26
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/26
- Re: libobjc2 still failing tests,
Andreas Fink <=
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/26
- Re: libobjc2 still failing tests, Andreas Fink, 2019/01/26
- Re: libobjc2 still failing tests, Andreas Fink, 2019/01/26
- Re: libobjc2 still failing tests, David Chisnall, 2019/01/26
- Re: libobjc2 still failing tests, Andreas Fink, 2019/01/26
- Re: libobjc2 still failing tests, Andreas Fink, 2019/01/25