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

YKLua - Segmentation fault error when running db.lua test #25

Closed
Pavel-Durov opened this issue Jul 19, 2023 · 3 comments
Closed

YKLua - Segmentation fault error when running db.lua test #25

Pavel-Durov opened this issue Jul 19, 2023 · 3 comments
Assignees

Comments

@Pavel-Durov
Copy link
Contributor

Pavel-Durov commented Jul 19, 2023

I get a Segmentation fault error when running src/lua -e"_U=true" all.lua after rebuilding yk

        Starting Tests
random seeds: 1689785445, 8060408
current path:
****/usr/local/share/lua/5.4/?.lua;/usr/local/share/lua/5.4/?/init.lua;/usr/local/lib/lua/5.4/?.lua;/usr/local/lib/lua/5.4/?/init.lua;./?.lua;./?/init.lua****

    ---- total memory: 44.8K, max memory: 44.8K ----

time: 2.5e-05 (+2.5e-05)

***** FILE 'main.lua'*****

Program received signal SIGSEGV, Segmentation fault.
0x000000000070a6eb in luaF_freeproto (L=0x7afdf8, f=0x7c1ea0) at lfunc.c:276
276             yk_location_drop(f->yklocs[i]);
(gdb) bt
#0  0x000000000070a6eb in luaF_freeproto (L=0x7afdf8, f=0x7c1ea0) at lfunc.c:276
#1  0x000000000070b79c in freeobj (L=0x7afdf8) at lgc.c:767
#2  0x000000000071101c in sweepgen (L=0x7afdf8, p=0x7aff30, limit=0x7da100, pfirstold1=0x7aff98) at lgc.c:1106
#3  0x0000000000710c37 in youngcollection (L=0x7afdf8, g=0x7afec0) at lgc.c:1239
#4  0x0000000000710469 in genstep (L=0x7afdf8, g=0x7afec0) at lgc.c:1434
#5  0x0000000000710249 in luaC_step (L=0x7afdf8) at lgc.c:1686
#6  0x00000000006fbc8b in lua_pushstring (L=0x7afdf8, s=0x7c1fd8 "tracegc") at lapi.c:553
#7  0x00000000007512b2 in findloader (L=0x7afdf8, name=<optimised out>) at loadlib.c:641
#8  0x0000000000750d95 in ll_require (L=0x7afdf8) at loadlib.c:666
#9  0x0000000000706444 in precallC (L=0x7afdf8, func=<optimised out>, nresults=<optimised out>, f=<optimised out>) at ldo.c:506
#10 0x0000000000706675 in luaD_precall (L=<optimised out>, func=<optimised out>, nresults=<optimised out>) at ldo.c:569
#11 0x0000000000743901 in luaV_execute (L=<optimised out>, ci=0x7b1820) at lvm.c:1667
#12 0x0000000000706ae8 in ccall (L=0x7afdf8, func=<optimised out>, nResults=<optimised out>, inc=65537) at ldo.c:609
#13 0x0000000000706b83 in luaD_callnoyield (L=0x7afdf8) at ldo.c:627
#14 0x00000000006fe92a in f_call (L=0x7afdf8) at lapi.c:1041
#15 0x000000000070465b in luaD_rawrunprotected (L=0x7afdf8, f=<optimised out>, ud=<optimised out>) at ldo.c:144
#16 0x0000000000707bce in luaD_pcall (L=0x7afdf8, old_top=80) at ldo.c:926
#17 0x00000000006fe75c in lua_pcallk (L=0x7afdf8, nargs=<optimised out>, nresults=<optimised out>, errfunc=<optimised out>, ctx=0, k=<optimised out>) at lapi.c:1067
#18 0x00000000006f82fd in docall (L=0x7afdf8, narg=<optimised out>, nres=-1) at lua.c:160
#19 0x00000000006f7e15 in handle_script (L=0x7afdf8, argv=<optimised out>) at lua.c:255
#20 0x00000000006f6fcc in pmain (L=<optimised out>) at lua.c:634
#21 0x0000000000706444 in precallC (L=0x7afdf8, func=<optimised out>, nresults=<optimised out>, f=<optimised out>) at ldo.c:506
#22 0x00000000007066bf in luaD_precall (L=<optimised out>, func=<optimised out>, nresults=<optimised out>) at ldo.c:572
#23 0x0000000000706a98 in ccall (L=0x7afdf8, func=<optimised out>, nResults=<optimised out>, inc=65537) at ldo.c:607
#24 0x0000000000706b83 in luaD_callnoyield (L=0x7afdf8) at ldo.c:627
#25 0x00000000006fe92a in f_call (L=0x7afdf8) at lapi.c:1041
#26 0x000000000070465b in luaD_rawrunprotected (L=0x7afdf8, f=<optimised out>, ud=<optimised out>) at ldo.c:144
#27 0x0000000000707bce in luaD_pcall (L=0x7afdf8, old_top=16) at ldo.c:926
#28 0x00000000006fe75c in lua_pcallk (L=0x7afdf8, nargs=<optimised out>, nresults=<optimised out>, errfunc=<optimised out>, ctx=0, k=<optimised out>) at lapi.c:1067
#29 0x00000000006f69b8 in main (argc=3, argv=<optimised out>) at lua.c:660

YK commit 52b3722069f0336cf6e10015ca2eb472ce9c5640

@ptersilie
Copy link
Contributor

Didn't we "fix" this by commenting out yk_location_drop(f->yklocs[i]);? Or is this still an issue?

@Pavel-Durov
Copy link
Contributor Author

This error was fixed by: #36
But we get another one :)

$ gdb --args ../src/lua -e"_U=true" all.lua

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

        Starting Tests
random seeds: 1692614285, 9530936
current path:
****/usr/local/share/lua/5.4/?.lua;/usr/local/share/lua/5.4/?/init.lua;/usr/local/lib/lua/5.4/?.lua;/usr/local/lib/lua/5.4/?/init.lua;./?.lua;./?/init.lua****

    ---- total memory: 35.9K, max memory: 35.9K ----

time: 2.9e-05 (+2.9e-05)

***** FILE 'main.lua'*****

Program received signal SIGSEGV, Segmentation fault.
core::sync::atomic::AtomicUsize::fetch_sub (self=0xfffffffffffffff0) at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/sync/atomic.rs:2540
2540    /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/sync/atomic.rs: No such file or directory.
(gdb) bt
#0  core::sync::atomic::AtomicUsize::fetch_sub (self=0xfffffffffffffff0)
    at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/sync/atomic.rs:2540
#1  alloc::sync::{impl#27}::drop<lock_api::mutex::Mutex<parking_lot::raw_mutex::RawMutex, ykrt::location::HotLocation>> (self=0x7fffffffcc20)
    at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/alloc/src/sync.rs:1864
#2  0x00007ffff7b062eb in core::ptr::drop_in_place<alloc::sync::Arc<lock_api::mutex::Mutex<parking_lot::raw_mutex::RawMutex, ykrt::location::HotLocation>>> ()
    at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/ptr/mod.rs:497
#3  0x00007ffff7b2eabe in core::mem::drop<alloc::sync::Arc<lock_api::mutex::Mutex<parking_lot::raw_mutex::RawMutex, ykrt::location::HotLocation>>> (_x=...)
    at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/mem/mod.rs:987
#4  0x00007ffff7b0a4c0 in ykrt::location::{impl#1}::drop (self=0x7fffffffcc78) at ykrt/src/location.rs:196
#5  0x00007ffff7b04d3b in core::ptr::drop_in_place<ykrt::location::Location> ()
    at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/ptr/mod.rs:497
#6  0x00007ffff7b04fdd in core::mem::drop<ykrt::location::Location> (_x=...) at /rustc/8c74a5d27c644a0f7a22bb2fa8dd3ff8257bc220/library/core/src/mem/mod.rs:987
#7  0x00007ffff7b04cdd in ykcapi::yk_location_drop (loc=...) at ykcapi/src/lib.rs:87
#8  0x000000000088aede in free_loc (f=<optimised out>, i=<optimised out>, idx=<optimised out>) at lyk.c:66
#9  0x000000000088b075 in yk_free_locactions (f=0x928c80) at lyk.c:76
#10 0x0000000000807c08 in luaF_freeproto (L=0x916e38, f=0x928c80) at lfunc.c:276
#11 0x000000000080a4ae in freeobj (L=0x916e38, o=0x928c80) at lgc.c:767
#12 0x0000000000815358 in deletelist (L=0x916e38, p=0x928c80, limit=<optimised out>) at lgc.c:1494
#13 0x0000000000815164 in luaC_freeallobjects (L=0x916e38) at lgc.c:1511
#14 0x000000000084fd4d in close_state (L=0x916e38) at lstate.c:276
#15 0x00000000008503ce in lua_close (L=0x916e38) at lstate.c:421
#16 0x00000000007d9aa0 in main (argc=<optimised out>, argv=<optimised out>) at lua.c:663

bors bot added a commit that referenced this issue Aug 25, 2023
64: Track initialised yk locations r=ltratt a=Pavel-Durov

Partially fixes (only for serial compilation)  - #62

# Changes

- Remove reallocarray in favour of calloc
- Change YkLocations to be stored as pointers
- Change lyk interface to reflect its "hooks" functionality
- Move tests to a separate test script and enable serialised all.lua test suite
- Added logging in lyk module for ease of debugging
- Updated readme

`test.sh` was tested for resiliency multiple times:
```shell
$ try_repeat -v 100 sh ./test.sh
``` 
# Issues

## Uninitialised locations memory 
`reallocarray` does not initialise memory with default zero bytes locations as `calloc`. 
Moving to `calloc` and using pointers allowed to check for NULL with default values set at initialisation time.

## Tests

When lua tests are executed one by one as single files it produces different results from when it's executed via `all.lua` test suite.

Example:

```shell

$ YKD_SERIALISE_COMPILATION=1 ../src/lua -e"_U=true" ./main.lua 
...
../src/lua: ./main.lua:343: assertion failed!
stack traceback:
        [C]: in function 'assert'
        ./main.lua:343: in main chunk
        [C]: in ?
```
When run through `all.lua` it passes:
```shell
$ YKD_SERIALISE_COMPILATION=1 ../src/lua -e"_U=true" ./all.lua 
...
***** FILE 'main.lua'*****
...
***** FILE 'gc.lua'*****
...
```
Since `all.lua` is what we base the stability of yklua, I think we should include it in the tests as is, currently only serialised compilation works.

Running `all.lua` prior to these changes results in error (`main/56c5787799b876f36babbae24e9afc025806b831`):
```
$ YKD_SERIALISE_COMPILATION=1 gdb -ex 'r' -ex 'bt' --args ../src/lua -e"_U=true" ./all.lua 
...
***** FILE 'main.lua'*****

Program received signal SIGSEGV, Segmentation fault.
core::sync::atomic::AtomicUsize::fetch_sub (self=<optimised out>) at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/sync/atomic.rs:2575
2575    /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/sync/atomic.rs: No such file or directory.
#0  core::sync::atomic::AtomicUsize::fetch_sub (self=<optimised out>) at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/sync/atomic.rs:2575
#1  alloc::sync::{impl#33}::drop<lock_api::mutex::Mutex<parking_lot::raw_mutex::RawMutex, ykrt::location::HotLocation>, alloc::alloc::Global> (self=0x7fffffffb410)
    at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/alloc/src/sync.rs:2370
#2  0x00007ffff7b0d4ab in core::ptr::drop_in_place<alloc::sync::Arc<lock_api::mutex::Mutex<parking_lot::raw_mutex::RawMutex, ykrt::location::HotLocation>, alloc::alloc::Global>> () at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/ptr/mod.rs:497
#3  0x00007ffff7b0067e in core::mem::drop<alloc::sync::Arc<lock_api::mutex::Mutex<parking_lot::raw_mutex::RawMutex, ykrt::location::HotLocation>, alloc::alloc::Global>> (_x=...) at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/mem/mod.rs:987
#4  0x00007ffff7b121f0 in ykrt::location::{impl#1}::drop (self=0x7fffffffb468) at ykrt/src/location.rs:197
#5  0x00007ffff7affa9b in core::ptr::drop_in_place<ykrt::location::Location> () at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/ptr/mod.rs:497
#6  0x00007ffff7aff6bd in core::mem::drop<ykrt::location::Location> (_x=...) at /rustc/ef85656a10657ba5e4f7fe2931a4ca6293138d51/library/core/src/mem/mod.rs:987
#7  0x00007ffff7b004bd in ykcapi::yk_location_drop (loc=...) at ykcapi/src/lib.rs:90
#8  0x000000000088aa0e in free_loc (f=<optimised out>, i=<optimised out>, idx=<optimised out>) at lyk.c:66
#9  0x000000000088aba5 in yk_free_locactions (f=0x928cc0) at lyk.c:76
--Type <RET> for more, q to quit, c to continue without paging--
#10 0x0000000000807738 in luaF_freeproto (L=0x916e38, f=0x928cc0) at lfunc.c:276
#11 0x0000000000809fde in freeobj (L=0x916e38, o=0x928cc0) at lgc.c:767
#12 0x0000000000817145 in sweepgen (L=0x916e38, g=<optimised out>, p=<optimised out>, limit=<optimised out>, pfirstold1=<optimised out>) at lgc.c:1106
#13 0x0000000000816713 in youngcollection (L=0x916e38, g=0x916f00) at lgc.c:1239
#14 0x000000000081557d in genstep (L=0x916e38, g=0x916f00) at lgc.c:1434
#15 0x0000000000815044 in luaC_step (L=0x916e38) at lgc.c:1686
#16 0x00000000007e4447 in lua_pushstring (L=0x916e38, s=<optimised out>) at lapi.c:553
#17 0x000000000089e60c in findloader (L=0x916e38, name=0x928df8 "tracegc") at loadlib.c:641
#18 0x000000000089de0a in ll_require (L=0x916e38) at loadlib.c:666
#19 0x00000000007fda75 in precallC (L=0x916e38, func=<optimised out>, nresults=<optimised out>, f=0x89db80 <ll_require>) at ldo.c:506
#20 0x00000000007fe016 in luaD_precall (L=0x916e38, func=0x923780, nresults=1) at ldo.c:569
#21 0x0000000000883f68 in luaV_execute (L=0x916e38, ci=<optimised out>) at lvm.c:1655
#22 0x00000000007feb3b in ccall (L=0x916e38, func=<optimised out>, nResults=<optimised out>, inc=<optimised out>) at ldo.c:609
#23 0x00000000007fec61 in luaD_callnoyield (L=0x916e38, func=0x917730, nResults=-1) at ldo.c:627
#24 0x00000000007eaf03 in f_call (L=0x916e38, ud=<optimised out>) at lapi.c:1041
#25 0x00000000007f8be7 in luaD_rawrunprotected (L=0x916e38, f=0x7eae40 <f_call>, ud=0x7ffff2487308) at ldo.c:144
#26 0x0000000000801406 in luaD_pcall (L=0x916e38, func=0x7eae40 <f_call>, u=0x7ffff2487308, old_top=<optimised out>, ef=<optimised out>) at ldo.c:926
#27 0x00000000007ea9ec in lua_pcallk (L=0x916e38, nargs=<optimised out>, nresults=<optimised out>, errfunc=<optimised out>, ctx=<optimised out>, k=<optimised out>)
    at lapi.c:1067
#28 0x00000000007dc623 in docall (L=0x916e38, narg=0, nres=-1) at lua.c:160
#29 0x00000000007dbd24 in handle_script (L=0x916e38, argv=<optimised out>) at lua.c:255
#30 0x00000000007d9fe3 in pmain (L=0x916e38) at lua.c:634
#31 0x00000000007fda75 in precallC (L=0x916e38, func=<optimised out>, nresults=<optimised out>, f=0x7d97f0 <pmain>) at ldo.c:506
#32 0x00000000007fe0c8 in luaD_precall (L=0x916e38, func=0x9176f0, nresults=1) at ldo.c:572
#33 0x00000000007fea7f in ccall (L=0x916e38, func=0x9176f0, nResults=1, inc=<optimised out>) at ldo.c:607
#34 0x00000000007fec61 in luaD_callnoyield (L=0x916e38, func=0x9176f0, nResults=1) at ldo.c:627
#35 0x00000000007eaf03 in f_call (L=0x916e38, ud=<optimised out>) at lapi.c:1041
#36 0x00000000007f8be7 in luaD_rawrunprotected (L=0x916e38, f=0x7eae40 <f_call>, ud=0x7ffff2487058) at ldo.c:144
#37 0x0000000000801406 in luaD_pcall (L=0x916e38, func=0x7eae40 <f_call>, u=0x7ffff2487058, old_top=<optimised out>, ef=<optimised out>) at ldo.c:926
#38 0x00000000007ea9ec in lua_pcallk (L=0x916e38, nargs=<optimised out>, nresults=<optimised out>, errfunc=<optimised out>, ctx=<optimised out>, k=<optimised out>)
    at lapi.c:1067
#39 0x00000000007d94b0 in main (argc=<optimised out>, argv=<optimised out>) at lua.c:660
```

That's cause we're freeing uninitialised yk locations.


Co-authored-by: Pavel Durov <[email protected]>
@Pavel-Durov
Copy link
Contributor Author

Duplicate of #38

@Pavel-Durov Pavel-Durov marked this as a duplicate of #38 Oct 2, 2023
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