X10
  1. X10
  2. XTENLANG-309

C++ version of examples/Constructs/GC/RemoteRef.x10 fails with exception in Clock_c register_c

    Details

    • Number of attachments :
      0

      Description

      Test runs successfully with the Java backend, fails with what I think is a ClockUseException with the C++ backend.

      It's entirely possible that the test program is buggy, or that it should fail on the Java backend but doesn't. Marking this as critical mainly because I can't make much progress on enabling GC until I can concoct a test program that runs on the C++ backend that actually does a few things with remote references that are locally dead so I can see if my registration code (not checked in yet) is actually working.

      When compiled with C++ backend for linux/x86 and run with manager/launcher, I get the following:

      [dgrove@linchen junk]$ /home/dgrove/x10-17/pgas/common/work/bin/launcher -t 2 ./a.out
      true
      at x10::lang::Throwable::fillInStackTrace()
      at x10aux::throwException(x10aux::ref<x10::lang::Throwable>)
      at x10::runtime::Clock_c::register_c()
      at x10_runtime_Runtime_closure_1::apply(int)
      at x10::lang::ValRail<int>::make(int, x10aux::ref<x10::lang::Fun_0_1<int, int> >)
      at x10::runtime::Runtime::runAsync(x10aux::ref<x10::lang::Place>, x10aux::ref<x10::lang::ValRail<x10aux::ref<x10::lang::Clock> > >, x10aux::ref<x10::lang::VoidFun_0_0>, x10aux::ref<x10::lang::String>)
      at RemoteRef::spawnRemoteTask(x10aux::ref<x10::lang::Clock>, int, x10aux::ref<RemoteRef__ResultHolder>)
      at RemoteRef::run()
      at harness::x10Test::execute()
      at RemoteRef::main(x10aux::ref<x10::lang::Rail<x10aux::ref<x10::lang::String> > >)
      at x10aux::BootStrapClosure::apply()
      at x10::runtime::Activity::run()
      at x10::runtime::Runtime::start(x10aux::ref<x10::lang::VoidFun_0_0>)
      at int x10aux::main<x10::runtime::Runtime, RemoteRef>(int, char**)
      at main
      at __libc_start_main
      at __gxx_personality_v0
      ++++++ Test failed.
      interrupt (job signalled)
      job terminated by signal 2 (Interrupt)

        Issue Links

          Activity

          Hide
          David Grove added a comment -

          And it could just be a bug with the implementation of Clocks & multi-process X10 that we haven't noticed yet since we haven't gotten test suite results with the C++ backend yet...

          Show
          David Grove added a comment - And it could just be a bug with the implementation of Clocks & multi-process X10 that we haven't noticed yet since we haven't gotten test suite results with the C++ backend yet...
          Hide
          David Grove added a comment -

          Verified that this is still a bug.

          [dgrove@linchen junk]$ runx10 a.out
          x10.lang.ClockUseException: clock use exception
          at x10::lang::Throwable::fillInStackTrace()
          at x10aux::throwException(x10aux::ref<x10::lang::Throwable>)
          at x10::runtime::Clock_c::register_c()
          at x10_runtime_Runtime_closure_1::apply(int)
          at x10::lang::ValRail<int>::make(int, x10aux::ref<x10::lang::Fun_0_1<int, int> >)
          at x10::runtime::Runtime::runAsync(x10aux::ref<x10::lang::Place>, x10aux::ref<x10::lang::ValRail<x10aux::ref<x10::lang::Clock> > >, x10aux::ref<x10::lang::VoidFun_0_0>, x10aux::ref<x10::lang::String>)
          at RemoteRef::spawnRemoteTask(x10aux::ref<x10::lang::Clock>, int, x10aux::ref<RemoteRef__ResultHolder>)
          at RemoteRef::run()
          at harness::x10Test::execute()
          at RemoteRef::main(x10aux::ref<x10::lang::Rail<x10aux::ref<x10::lang::String> > >)
          at x10aux::BootStrapClosure::apply()
          at x10::runtime::Activity::run()
          at x10::runtime::Runtime::start(x10aux::ref<x10::lang::VoidFun_0_0>)
          at int x10aux::main<x10::runtime::Runtime, RemoteRef>(int, char**)
          at main
          at __libc_start_main
          at __gxx_personality_v0
          ++++++ Test failed.

          Show
          David Grove added a comment - Verified that this is still a bug. [dgrove@linchen junk] $ runx10 a.out x10.lang.ClockUseException: clock use exception at x10::lang::Throwable::fillInStackTrace() at x10aux::throwException(x10aux::ref<x10::lang::Throwable>) at x10::runtime::Clock_c::register_c() at x10_runtime_Runtime_ closure _1::apply(int) at x10::lang::ValRail<int>::make(int, x10aux::ref<x10::lang::Fun_0_1<int, int> >) at x10::runtime::Runtime::runAsync(x10aux::ref<x10::lang::Place>, x10aux::ref<x10::lang::ValRail<x10aux::ref<x10::lang::Clock> > >, x10aux::ref<x10::lang::VoidFun_0_0>, x10aux::ref<x10::lang::String>) at RemoteRef::spawnRemoteTask(x10aux::ref<x10::lang::Clock>, int, x10aux::ref<RemoteRef__ResultHolder>) at RemoteRef::run() at harness::x10Test::execute() at RemoteRef::main(x10aux::ref<x10::lang::Rail<x10aux::ref<x10::lang::String> > >) at x10aux::BootStrapClosure::apply() at x10::runtime::Activity::run() at x10::runtime::Runtime::start(x10aux::ref<x10::lang::VoidFun_0_0>) at int x10aux::main<x10::runtime::Runtime, RemoteRef>(int, char**) at main at __libc_start_main at __gxx_personality_v0 ++++++ Test failed.
          Hide
          Olivier Tardieu added a comment - - edited

          hashtable lookup of clock in clockPhases fails due to equals method returning an incorrect result

          Show
          Olivier Tardieu added a comment - - edited hashtable lookup of clock in clockPhases fails due to equals method returning an incorrect result
          Hide
          David Grove added a comment -

          Still failing (r7852) but with a different exception (appended). Still probably a symptom of equals on values not being right.

          Uncaught exception at place 0 of type: x10.lang.ClassCastException
          x10.lang.ClassCastException: 
                  at x10::lang::Throwable::fillInStackTrace()
                  at x10aux::throwException(x10aux::ref<x10::lang::Throwable>)
                  at void x10aux::throwException<x10::lang::ClassCastException>()
                  at x10aux::ClassCastBothRef<x10::lang::Ref, x10::runtime::Clock_c>::_(x10aux::ref<x10::runtime::Clock_c>)
                  at x10aux::ClassCastNotPrimitive<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >::_(x10aux::ref<x10::runtime::Clock_c>)
                  at x10aux::ClassCastPrimitive<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >::_(x10aux::ref<x10::runtime::Clock_c>)
                  at x10aux::ClassCast<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >::_(x10aux::ref<x10::runtime::Clock_c>)
                  at x10aux::ref<x10::lang::Ref> x10aux::class_cast<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >(x10aux::ref<x10::runtime::Clock_c>)
                  at x10::util::HashMap<x10aux::ref<x10::runtime::Clock_c>, int>::getEntry(x10aux::ref<x10::runtime::Clock_c>)
                  at x10::util::HashMap<x10aux::ref<x10::runtime::Clock_c>, int>::get(x10aux::ref<x10::runtime::Clock_c>)
                  at x10::util::HashMap<x10aux::ref<x10::runtime::Clock_c>, int>::apply(x10aux::ref<x10::runtime::Clock_c>)
                  at x10::runtime::Clock_c::ph_c()
                  at x10::runtime::Clock_c::drop_c()
                  at x10::runtime::ClockPhases::drop()
                  at x10::runtime::Activity::drop()
                  at x10::runtime::Activity::now()
                  at x10::runtime::Runtime::start(x10aux::ref<x10::lang::VoidFun_0_0>)
                  at int x10aux::template_main<x10::runtime::Runtime, RemoteRef>(int, char**)
                  at main
                  at __libc_start_main
                  at __gxx_personality_v0
          
          Show
          David Grove added a comment - Still failing (r7852) but with a different exception (appended). Still probably a symptom of equals on values not being right. Uncaught exception at place 0 of type: x10.lang.ClassCastException x10.lang.ClassCastException: at x10::lang::Throwable::fillInStackTrace() at x10aux::throwException(x10aux::ref<x10::lang::Throwable>) at void x10aux::throwException<x10::lang::ClassCastException>() at x10aux::ClassCastBothRef<x10::lang::Ref, x10::runtime::Clock_c>::_(x10aux::ref<x10::runtime::Clock_c>) at x10aux::ClassCastNotPrimitive<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >::_(x10aux::ref<x10::runtime::Clock_c>) at x10aux::ClassCastPrimitive<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >::_(x10aux::ref<x10::runtime::Clock_c>) at x10aux::ClassCast<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >::_(x10aux::ref<x10::runtime::Clock_c>) at x10aux::ref<x10::lang::Ref> x10aux::class_cast<x10aux::ref<x10::lang::Ref>, x10aux::ref<x10::runtime::Clock_c> >(x10aux::ref<x10::runtime::Clock_c>) at x10::util::HashMap<x10aux::ref<x10::runtime::Clock_c>, int >::getEntry(x10aux::ref<x10::runtime::Clock_c>) at x10::util::HashMap<x10aux::ref<x10::runtime::Clock_c>, int >::get(x10aux::ref<x10::runtime::Clock_c>) at x10::util::HashMap<x10aux::ref<x10::runtime::Clock_c>, int >::apply(x10aux::ref<x10::runtime::Clock_c>) at x10::runtime::Clock_c::ph_c() at x10::runtime::Clock_c::drop_c() at x10::runtime::ClockPhases::drop() at x10::runtime::Activity::drop() at x10::runtime::Activity::now() at x10::runtime:: Runtime ::start(x10aux::ref<x10::lang::VoidFun_0_0>) at int x10aux::template_main<x10::runtime:: Runtime , RemoteRef>( int , char **) at main at __libc_start_main at __gxx_personality_v0
          Hide
          Igor Peshansky added a comment -

          This is a bug either in HashMap or in the boxing code. The HashMap implementation compares the key to null, even though the key in this case is of a value class, and thus not nullable. If this pattern is valid, then the key ought to be explicitly boxed in the frontend compiler. Otherwise this code should not typecheck.

          This does not manifest in Java, because non-primitive values are Java classes, and are nullable (regardless of what X10 says), and primitive values are auto-boxed.

          Show
          Igor Peshansky added a comment - This is a bug either in HashMap or in the boxing code. The HashMap implementation compares the key to null, even though the key in this case is of a value class, and thus not nullable. If this pattern is valid, then the key ought to be explicitly boxed in the frontend compiler. Otherwise this code should not typecheck. This does not manifest in Java, because non-primitive values are Java classes, and are nullable (regardless of what X10 says), and primitive values are auto-boxed.
          Hide
          Igor Peshansky added a comment -

          Fixed by r7926.

          Show
          Igor Peshansky added a comment - Fixed by r7926.
          Hide
          David Grove added a comment -

          Bulk close of old resolved issues.

          Show
          David Grove added a comment - Bulk close of old resolved issues.

            People

            • Assignee:
              Igor Peshansky
              Reporter:
              David Grove
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: