Probable GC problem on MacOS (manifests as RTT assertion failure)

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix
  • Affects Version/s: X10 2.0.2
  • Fix Version/s: X10 2.0.3
  • Component/s: Native X10: Compiler Codegen
  • Labels:
    None
  • Environment:
    condor.watson.ibm.com (macos_x86 with shared libraries and GC)

Description

Comparing what should be equivalent regression tests runs between condor (MacOS) and triloka22 (linux), one can see that there are about 30 more test failes on MacOS than on Linux.

https://x10.watson.ibm.com/cattrack/compare?firstRun=3130&secondRun=3131

I spot checked half a dozen of the condor test failures, and they were all due to an assertion failure that RTTs are not being properly initialized. This seems very likely to be related to C++ static initialization not being done properly in the presence of shared libraries. (At least that was the diagnosis for a similar error on cygwin).

I suspect we may need to disable building with shared libs on MacOS until we can investigate the problem further and determine if there is some way to get the static initialization and/or dynamic linking to do the right thing (or at least the same thing it is doing on Linux, which seems to work).

Issue Links

relates to

Bug - A problem which impairs or prevents the functions of the product. XTENLANG-1116 Itable lookup failure with shared libraries on Cygwin

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
David Grove added a comment -

Linking to cygwin shared library issue.

Show
David Grove added a comment - Linking to cygwin shared library issue.
Hide
Permalink
Igor Peshansky added a comment -

It is not related to shared libraries – building with static libs reproduces the failure. However, building without GC causes the test to succeed, with both shared and static libraries.

Show
Igor Peshansky added a comment - It is not related to shared libraries – building with static libs reproduces the failure. However, building without GC causes the test to succeed, with both shared and static libraries.
Hide
Permalink
Olivier Tardieu added a comment -

investigated this further using PolyProduct1 test case
-x10rt standalone
-arch i386
running single place
X10_NTHREADS=1
X10_STATIC_THREADS=1

compiling dynamic libs on 10.5.8
building final executable on 10.5.8
-> failure with GC
-> ok without GC, valgrind reports no error

using same dynamic libs from 10.5.8
building final executable on 10.6.2
-> ok with GC

Show
Olivier Tardieu added a comment - investigated this further using PolyProduct1 test case -x10rt standalone -arch i386 running single place X10_NTHREADS=1 X10_STATIC_THREADS=1 compiling dynamic libs on 10.5.8 building final executable on 10.5.8 -> failure with GC -> ok without GC, valgrind reports no error using same dynamic libs from 10.5.8 building final executable on 10.6.2 -> ok with GC
Hide
Permalink
Olivier Tardieu added a comment -

We have established that the garbage collector does not find some of the static roots when dealing with an application compiled with g++ on Leopard (10.5). We're hacking around this by manually registering the heap-references from the RTT objects. This isn't a real solution, because we can't manually register heap-references for user-defined static fields of generic classes. This is therefore not likely to be fixed ever... The good news is there is no such problem with g++ on Snow Leopard (10.6).

Show
Olivier Tardieu added a comment - We have established that the garbage collector does not find some of the static roots when dealing with an application compiled with g++ on Leopard (10.5). We're hacking around this by manually registering the heap-references from the RTT objects. This isn't a real solution, because we can't manually register heap-references for user-defined static fields of generic classes. This is therefore not likely to be fixed ever... The good news is there is no such problem with g++ on Snow Leopard (10.6).
Hide
Permalink
David Grove added a comment -

bulk close of all resolved issues as part of closing 2.0.4 items.

Show
David Grove added a comment - bulk close of all resolved issues as part of closing 2.0.4 items.

People

  • Assignee:
    Olivier Tardieu
    Reporter:
    David Grove
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: