Re: libobjc2 still failing tests

[Andreas Fink]

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