X10

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

depends upon

Bug - A problem which impairs or prevents the functions of the product. XTENLANG-322 v.equals(v) returns false for x10 values

  • Blocker - Blocks development and/or testing work, production could not run
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
is depended upon by

New Feature - A new feature of the product, which has yet to be developed. XTENLANG-226 Track remote references to enable local GC

  • Major - Major loss of function.
  • 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 -

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...
David Grove made changes -
Field Original Value New Value
Assignee Igor Peshansky [ ipeshansky ] Olivier Tardieu [ tardieu ]
Hide
Permalink
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.
Olivier Tardieu made changes -
Link This issue depends upon XTENLANG-322 [ XTENLANG-322 ]
Hide
Permalink
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
Olivier Tardieu made changes -
Assignee Olivier Tardieu [ tardieu ] Igor Peshansky [ ipeshansky ]
David Grove made changes -
Link This issue is depended upon by XTENLANG-226 [ XTENLANG-226 ]
Hide
Permalink
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
Permalink
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.
Igor Peshansky made changes -
Assignee Igor Peshansky [ ipeshansky ] Nate Nystrom [ nystrom ]
Igor Peshansky made changes -
Assignee Nate Nystrom [ nystrom ] Igor Peshansky [ ipeshansky ]
Igor Peshansky made changes -
Status Open [ 1 ] In Progress [ 3 ]
Hide
Permalink
Igor Peshansky added a comment -

Fixed by r7926.

Show
Igor Peshansky added a comment - Fixed by r7926.
Igor Peshansky made changes -
Status In Progress [ 3 ] Resolved [ 5 ]
Resolution Fixed [ 1 ]
Hide
Permalink
David Grove added a comment -

Bulk close of old resolved issues.

Show
David Grove added a comment - Bulk close of old resolved issues.
David Grove made changes -
Status Resolved [ 5 ] Closed [ 6 ]

People

  • Assignee:
    Igor Peshansky
    Reporter:
    David Grove
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: