libobjc2
libobjc2 copied to clipboard
Current master: A few tests failed on macOS.
I thought this might be interesting to report:
95% tests passed, 8 tests failed out of 158
Total Test time (real) = 28.51 sec
The following tests FAILED:
57 - PropertyAttributeTest (Child aborted)
58 - PropertyAttributeTest_optimised (Child aborted)
59 - PropertyAttributeTest_legacy (Child aborted)
60 - PropertyAttributeTest_legacy_optimised (Child aborted)
61 - ProtocolExtendedProperties (Child aborted)
62 - ProtocolExtendedProperties_optimised (Child aborted)
149 - category_properties (Child aborted)
150 - category_properties_optimised (Child aborted)
Errors while running CTest
FAILED: CMakeFiles/test.util
cd /Users/Ingwie/Work/Git/libobjc2/out && /usr/local/Cellar/cmake/3.13.4/bin/ctest --force-new-ctest-process
ninja: build stopped: subcommand failed.
[email protected] ~/W/G/l/out $ sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.3
BuildVersion: 18D42
[email protected] ~/W/G/l/out $ cd ..; git rev-parse HEAD
d015f0160cfeb3097c8d2321c0bfc648c0885047
Hope it helps :)
I haven't tested on macOS for a while, but the current code in clang doesn't support Mach-O platforms for the new ABI, so I'm not totally surprised things are broken - all of the non-_legacy tests are actually running their legacy versions. category_properties and ProtocolExtendedProperties are expected fails, because the old ABI doesn't support the things that they're testing.
It would be helpful to see a stack trace of PropertyAttributeTest to see where it's failing.
If you can tell me how I can force a stacktrace to be shown, I’d be happy to provide it. :)
Am 13.02.2019 um 10:25 schrieb David Chisnall [email protected]:
I haven't tested on macOS for a while, but the current code in clang doesn't support Mach-O platforms for the new ABI, so I'm not totally surprised things are broken - all of the non-_legacy tests are actually running their legacy versions. category_properties and ProtocolExtendedProperties are expected fails, because the old ABI doesn't support the things that they're testing.
It would be helpful to see a stack trace of PropertyAttributeTest to see where it's failing.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gnustep/libobjc2/issues/84#issuecomment-463123561, or mute the thread https://github.com/notifications/unsubscribe-auth/ACwnlOo9gRj_Ez1jrQJmyFXf3H8tyF7rks5vM9oagaJpZM4a37P9.
The tests are individual binaries in the Test subdirectory of your build directory. You can run them in your favourite debugger to get a stack trace - they should fail either by crashing (hopefully not!) or by an assert failing (hopefully). I think the rpath stuff works on macOS so it will find libobjc.dyld in the build directory, but if not then set the DYLD_LIBRARY_PATH environment variable to the build directory before running the test.
(lldb) r
Process 71324 launched: '/Users/Ingwie/Work/git/libobjc2/out/Test/PropertyAttributeTest' (x86_64)
Assertion failed: (outCount == 1), function main, file ../Test/PropertyAttributeTest.m, line 43.
Process 71324 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
frame #0: 0x00007fff7e08a23e libsystem_kernel.dylib`__pthread_kill + 10
libsystem_kernel.dylib`__pthread_kill:
-> 0x7fff7e08a23e <+10>: jae 0x7fff7e08a248 ; <+20>
0x7fff7e08a240 <+12>: movq %rax, %rdi
0x7fff7e08a243 <+15>: jmp 0x7fff7e0843b7 ; cerror_nocancel
0x7fff7e08a248 <+20>: retq
Target 0: (PropertyAttributeTest) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
* frame #0: 0x00007fff7e08a23e libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x00007fff7e140c1c libsystem_pthread.dylib`pthread_kill + 285
frame #2: 0x00007fff7dff31c9 libsystem_c.dylib`abort + 127
frame #3: 0x00007fff7dfbb868 libsystem_c.dylib`__assert_rtn + 320
frame #4: 0x0000000100001648 PropertyAttributeTest`main at PropertyAttributeTest.m:43
frame #5: 0x00007fff7df4aed9 libdyld.dylib`start + 1
frame #6: 0x00007fff7df4aed9 libdyld.dylib`start + 1
There you go! :)
Thanks. In frame 4, is the value of outCount 0? It looks as if we're not seeing class property metadata, which is probably expected with older clang builds. If you feel like it, I'd be interested in seeing if these go away with a recent clang from homebrew, but it's not very important.
You mean line Clang 7? I have a few LLVMs installed:
[email protected] ~/W/g/l/out $ find /usr/local/Cellar/ -name clang | grep "toolchain" | grep "bin/clang" | xargs -t -I % sh -c '% --version'
sh -c /usr/local/Cellar//llvm@6/6.0.1_1/Toolchains/LLVM6.0.1.xctoolchain/usr/bin/clang --version
clang version 6.0.1 (tags/RELEASE_601/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /usr/local/Cellar//llvm@6/6.0.1_1/Toolchains/LLVM6.0.1.xctoolchain/usr/bin
sh -c /usr/local/Cellar//llvm/7.0.1/Toolchains/LLVM7.0.1.xctoolchain/usr/bin/clang --version
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /usr/local/Cellar//llvm/7.0.1/Toolchains/LLVM7.0.1.xctoolchain/usr/bin
sh -c /usr/local/Cellar//[email protected]/3.9.1_2/Toolchains/LLVM3.9.1.xctoolchain/usr/bin/clang --version
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /usr/local/Cellar//[email protected]/3.9.1_2/Toolchains/LLVM3.9.1.xctoolchain/usr/bin
sh -c /usr/local/Cellar//llvm@5/5.0.2_1/Toolchains/LLVM5.0.2.xctoolchain/usr/bin/clang --version
clang version 5.0.2 (tags/RELEASE_502/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /usr/local/Cellar//llvm@5/5.0.2_1/Toolchains/LLVM5.0.2.xctoolchain/usr/bin
sh -c /usr/local/Cellar//llvm@4/4.0.1_1/Toolchains/LLVM4.0.1.xctoolchain/usr/bin/clang --version
clang version 4.0.1 (tags/RELEASE_401/final)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir: /usr/local/Cellar//llvm@4/4.0.1_1/Toolchains/LLVM4.0.1.xctoolchain/usr/bin
Can you try with clang 8?
Mach-O object files are not supported by the next gen ABI. Closing this.