Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The VM crashed when the asm_open was added to the bc file #1486

Open
HopeDevote opened this issue Aug 27, 2024 · 4 comments
Open

The VM crashed when the asm_open was added to the bc file #1486

HopeDevote opened this issue Aug 27, 2024 · 4 comments

Comments

@HopeDevote
Copy link

Hello, sorry to bother you

When I legally added the asm_open instruction(line 3:vasm_open 7, 3, True, c4(7), s25(7) # 1 ) to the instruction set of the bc file

# test_array_muls-0--0
ldsi s0, 3 # 0
vasm_open 7, 3, True, c4(7), s25(7) # 1
stms s0, 8192 # 2
ldsi s1, 2 # 3
stms s1, 8195 # 4
ldsi s2, 4 # 5
stms s2, 8193 # 6
ldsi s3, 3 # 7
stms s3, 8196 # 8
ldsi s4, 5 # 9
stms s4, 8194 # 10
ldsi s5, 4 # 11
stms s5, 8197 # 12
vldms 3, s6(3), 8192 # 13
vldms 3, s12(3), 8195 # 14
muls 4, 3, s15(3), s12(3), s6(3) # 15
ldms s18, 8192 # 16
ldms s19, 8193 # 17
ldms s20, 8194 # 18
ldms s22, 8195 # 19
ldms s23, 8196 # 20
ldms s24, 8197 # 21
dotprods 8, 8, s21, s18, s22, s19, s23, s20, s24 # 22
vasm_open 3, 3, True, c0(3), s15(3) # 23
vprint_reg_plain 3, c0(3) # 24
print_char 10 # 25
asm_open 3, True, c3, s21 # 26
print_reg_plain c3 # 27
print_char 10 # 28

run ./emulate.x test_array_muls
the VM crashed
Fatal error: vector::_M_range_check: __n (which is 16) >= this->size() (which is 16)

Is this a bug or expected behavior?

Thanks!

@mkskeller
Copy link
Member

The virtual machine only considers registers that are written to when calculating the register requirements. It seems you have added registers (s25...) that are only written to but never read from. I would argue this contradicts the idea of the bytecode.

@HopeDevote
Copy link
Author

Hello,
It seems that a similar issue has occurred again. Even though all registers in the generated bc file are both written to and read from, the following error still exists:
Using statistical security parameter 40 Trying to run 64-bit computation Fatal error: vector::_M_range_check: __n (which is 84) >= this->size() (which is 84)

Replay

  1. The command to compile test.mpc is ./compile.py -R 64 test. The files generated are as follows:
    test.zip

  2. ./emulate.x test

  3. gdb --args ./emulate.x test

GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.2) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emulate.x...
(gdb) catch throw
Catchpoint 1 (throw)
(gdb) run
Starting program: /home/doerlee/MPC/mp-spdz-0.3.9/emulate.x test
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Using statistical security parameter 40
Trying to run 64-bit computation
[New Thread 0x7ffff47df700 (LWP 15256)]
[Switching to Thread 0x7ffff47df700 (LWP 15256)]

Thread 2 "emulate.x" hit Catchpoint 1 (exception thrown), 0x00007ffff7808662 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) bt
#0  0x00007ffff7808662 in __cxa_throw () from /lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x000000000059bdeb in Preprocessing<GC::FakeSecret>::get_part (this=<optimized out>) at ./Processor/Data_Files.h:194
#2  0x0000000000550a58 in Data_Files<FakeShare<SignedZ2<64> >, FakeShare<gf2n_long> >::total_time (this=<optimized out>) at ./Processor/Data_Files.hpp:427
#3  0x000000000052abd2 in thread_info<FakeShare<SignedZ2<64> >, FakeShare<gf2n_long> >::Sub_Main_Func (this=<optimized out>)
    at ./Processor/Online-Thread.hpp:270
#4  0x0000000000528331 in thread_info<FakeShare<SignedZ2<64> >, FakeShare<gf2n_long> >::Main_Func_With_Purge (this=<optimized out>)
    at ./Processor/Online-Thread.hpp:434
#5  0x0000000000525eeb in thread_info<FakeShare<SignedZ2<64> >, FakeShare<gf2n_long> >::Main_Func (ptr=<optimized out>)
    at ./Processor/Online-Thread.hpp:415
#6  0x00007ffff75f2609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7  0x00007ffff74f6353 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

@mkskeller
Copy link
Member

Thank you for raising this. You should find that e87000f fixes it.

@mkskeller mkskeller reopened this Dec 3, 2024
@HopeDevote
Copy link
Author

Thank you for raising this. You should find that e87000f fixes it.

Thanks! I have tested your fix, and the issue has been resolved successfully.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
@mkskeller @HopeDevote and others