'funcRELUPrime' function produces inconsistent 'b' sharing when printed by different parties

[lcy5201314]

Description

Hi, I discovered while running inference that the funcRELUPrime function produces inconsistent sharing of b when printed by different parties. Since the random number is 0, the final calculation result is correct.

I added the following code in funcRELUPrime to get the result

void funcRELUPrime(const RSSVectorMyType &a, RSSVectorSmallType &b, size_t size)
{
    log_print("funcRELUPrime");

    RSSVectorMyType twoA(size);
    RSSVectorSmallType theta(size);
    for (int i = 0; i < size; ++i)
        twoA[i] = a[i] << 1;

    // cout << "Wrap: \t\t" << funcTime(funcWrap, twoA, theta, size) << endl;
    funcWrap(twoA, theta, size);

    for (int i = 0; i < size; ++i)
    {
        b[i].first = theta[i].first ^ (getMSB(a[i].first));
        b[i].second = theta[i].second ^ (getMSB(a[i].second));
    }
        // cout << "---------------------------------------------------------"<<endl;
    // for (size_t i = 0; i < 50; ++i){
    //  cout << (int)b[i].first << "  ";
    // }
    // cout << endl;
    // for (size_t i = 0; i < 50; ++i){
    //  cout << (int)b[i].second << "  ";
    // }
    // cout << endl;
    // print_vector(b, "FLOAT", "b - v", 50);
    // cout << "---------------------------------------------------------"<<endl;
}   

Expected Behavior

The b shares should be consistent across all parties after the funcRELUPrime function is executed.

Actual Behavior

The b shares are inconsistent, as demonstrated by the following outputs from different parties:

Party A:

0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
b - v 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0

Party B:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
b - v 0 0 1 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 1 0 0 0 0 0 1 0 0 0 0 1 1 1 0 0 1 1 0 0 0 0 1 1 0 0 0 0 0 1 0 0

Party C:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 1 0 0 1 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 1 1 1 1 0 0 0 1 1 0 0 1 1 1 1 0 0 1 1 1 1 1 0 1 1
b - v 1 1 0 0 1 1 0 1 1 1 1 1 1 1 1 1 0 1 0 1 1 1 1 1 0 1 1 1 1 0 0 0 1 1 0 0 1 1 1 1 0 0 1 1 1 1 1 0 1 1

[snwagh]

@lcy5201314 There does seem to be some issue based on your output. Party B having all zeros is fine but the .first and .second of the first and third party respectively should agree. I won't have the bandwidth to probe into this but can you check the following:

• Check if the static casting in this line is an issue: cout << (int)b[i].first << " ";
• Could you break down the function into it parts and see where the consistency is violated first? You can write a small function that will check if a variable is consistent and then use it inside your code.
• I don't remember if I wrote the funcTime method but check if it does not cause any trouble by running the function inside it.

There is a very real possibility of you hitting a bug, please send a patch if you manage to fix it.

[lcy5201314]

Thank you for your reply. I will check the details of the error in detail later.