Question about Party::Reset() semantics when modularizing share wrappers (program hangs without crash)

[ydicsey]

Hi MOTION team,

I am currently experimenting with modularizing share wrappers on top of MOTION, and I ran into a question regarding the semantics and guarantees of Party::Reset().

What I am trying to do

I would like to structure my program as multiple computation rounds within the same process:

1. Build a circuit / create shares
2. Execute party->Run()
3. Extract shared outputs
4. Call party->Reset()
5. Build a new circuit and run another round

This is needed to support a modular share-wrapper abstraction where intermediate results are finalized and then reused in later computations.

Expected behavior

After calling party->Reset(), I expected the Party instance to be in a clean state such that:

• A new circuit can be constructed
• New shares can be created
• party->Run() can be safely called again

Actual behavior

In practice, after party->Reset():

• The program enters a state where execution hangs
• There is no segmentation fault or exception
• The process simply stops making progress (typically during the next Run() or shortly before)

This behavior is deterministic and reproducible.

Minimal example (simplified)

class SHR {
 public:
  // Construct an integer input share and immediately Run + Reset,
  // then store a "shared" value for later modular use.
  SHR(std::int64_t x, encrypto::motion::Party* party, std::size_t input_owner)
      : party_(party), owner_id_(input_owner) {
    shares_ = party_->In<encrypto::motion::MpcProtocol::kArithmeticGmw>(x, input_owner);
    party_->Run();
    data_ = shares_.As<std::uint64_t>();
    party_->Reset();
}

main(){
PartyPointer party = CreateParty(parties_arg, my_id);

    SHR a = SHR(19, party.get(), 0);
    // program hangs when i call party_run second times
    SHR b = SHR(20, party.get(), 1);
}