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.

Sign up for GitHub

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

Jump to bottom

Segmentation fault in field_map_get_offset #10123

Closed
ligurio opened this issue Jun 10, 2024 · 0 comments · Fixed by #10124
Closed

Segmentation fault in field_map_get_offset #10123

ligurio opened this issue Jun 10, 2024 · 0 comments · Fixed by #10124
Assignees
@locker
Labels
2.11 Target is 2.11 and all newer release/master branches 3.1 Target is 3.1 and all newer release/master branches bug Something isn't working crash vinyl

Comments

@ligurio
Copy link
Member

ligurio commented Jun 10, 2024 •
edited

Bug description

  • OS: Linux
  • OS Version: 22.04
  • Architecture: amd64

Tarantool 3.2.0-entrypoint-69-gbde28f0faa
Target: Linux-x86_64-Debug
Build options: cmake . -DCMAKE_INSTALL_PREFIX=/usr/local -DENABLE_BACKTRACE=TRUE
Compiler: GNU-11.4.0
C_FLAGS: -fexceptions -funwind-tables -fasynchronous-unwind-tables -fno-common -msse2 -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -fmacro-prefix-map=/home/sergeyb/sources/MRG/tarantool=. -std=c11 -Wall -Wextra -Wno-gnu-alignof-expression -fno-gnu89-inline -Wno-cast-function-type -Werror -g -ggdb -O0
CXX_FLAGS: -fexceptions -funwind-tables -fasynchronous-unwind-tables -fno-common -msse2 -Wformat -Wformat-security -Werror=format-security -fstack-protector-strong -fPIC -fmacro-prefix-map=/home/sergeyb/sources/MRG/tarantool=. -std=c++11 -Wall -Wextra -Wno-invalid-offsetof -Wno-gnu-alignof-expression -Wno-cast-function-type -Werror -g -ggdb -O0

Steps to reproduce

Actually, there are no exact steps to reproduce.

Actual behavior


<snipped> 

2024-06-10 17:01:32.383 [1719825] main/351/WRK #238 memtx_tx.c:698 W> Transaction committing DDL (id=30844) has aborted another TX (id=30841)      
2024-06-10 17:01:32.383 [1719825] main/351/WRK #238 memtx_tx.c:698 W> Transaction committing DDL (id=30844) has aborted another TX (id=30842)      
2024-06-10 17:01:32.383 [1719825] main/351/WRK #238 memtx_tx.c:698 W> Transaction committing DDL (id=30844) has aborted another TX (id=30843)      
2024-06-10 17:01:32.383 [1719825] main/380/WRK #267/vinyl I> ["INDEX_STAT_OP",[]]                                                                  
2024-06-10 17:01:32.383 [1719825] main/185/WRK #72/vinyl I> ["SNAPSHOT_OP",[]]                                                                     
2024-06-10 17:01:32.383 [1719825] main/185/WRK #72/vinyl I> ERROR: Snapshot is already in progress                                                 
2024-06-10 17:01:32.383 [1719825] main/251/WRK #138/vinyl I> ["DELETE_OP",[[383183175824]]]                                                        
2024-06-10 17:01:32.383 [1719825] main/297/WRK #184/vinyl I> ["INSERT_OP",[[false,308202823459,"9154df4a-e340-49d0-addf-b2b6435534e3",604625733375.
03,"d64f683b-936f-423c-87f2-1e104d8dac46"]]]                                                                                                       
2024-06-10 17:01:32.384 [1719825] main/297/WRK #184/vinyl I> ERROR: Duplicate key exists in unique index "idx_1" in space "fllitjfvht" with old tup
le - [false, 308202823459, 9154df4a-e340-49d0-addf-b2b6435534e3, 6.04626e+11, d64f683b-936f-423c-87f2-1e104d8dac46] and new tuple - [false, 3082028
23459, 9154df4a-e340-49d0-addf-b2b6435534e3, 6.04626e+11, d64f683b-936f-423c-87f2-1e104d8dac46]                                                    
2024-06-10 17:01:32.384 [1719825] main/181/WRK #68/vinyl I> ["REPLACE_OP",[[true,565528494584,"724adeae-8ee0-4b17-899c-e2f223b2985c",483664694269.4
1,"d1ea7f34-e6e6-4a00-93f2-0d16bf321f23"]]]                                                                                                        
2024-06-10 17:01:32.384 [1719825] main/281/WRK #168/vinyl I> ["SELECT_OP",[[372678259431]]]                                                        
2024-06-10 17:01:32.384 [1719825] main/281/WRK #168/vinyl I> ERROR: Transaction has been aborted by conflict                                       
2024-06-10 17:01:32.384 [1719825] main/370/WRK #257/vinyl I> ["UPDATE_OP",[[48151844117],[["!",1,true]]]]                                          
2024-06-10 17:01:32.384 [1719825] main/239/WRK #126/vinyl I> ["UPSERT_OP",[[true,361526234317,"e3662142-9bcb-43f1-bb21-eb5ce796f9a0",972188333865.1
4,"843d0dbd-12e7-4b9e-a557-c1b0f8101aa3"],[["=",3,"e5ad2535-fb88-49f5-b53b-bdb2110f5f7b"]]]]                                                       
2024-06-10 17:01:32.384 [1719825] main/165/WRK #52/vinyl I> ["BSIZE_OP",[]]                                                                        
2024-06-10 17:01:32.384 [1719825] main/147/WRK #34/vinyl I> ["LEN_OP",[]]                                                                          
2024-06-10 17:01:32.384 [1719825] main/138/WRK #25/vinyl I> ["TX_BEGIN",[]]                                                                        
2024-06-10 17:01:32.384 [1719825] main/279/WRK #166/vinyl I> ["TX_COMMIT",[]]                                                                      
2024-06-10 17:01:32.384 [1719825] main/265/WRK #152/vinyl I> ["TX_ROLLBACK",[]]                                                                    
2024-06-10 17:01:32.384 [1719825] main/308/WRK #195/vinyl I> ["INDEX_COUNT_OP",[]] 
Segmentation fault                                                                                                                                 

#1  0x590be9f7eb6d in crash_collect+256                                                                                                            
#2  0x590be9f7f5a9 in crash_signal_cb+100                                                                                                          
#3  0x72b111642520 in __sigaction+80                                                                                                               
#4  0x590bea385e3c in load_u32+35                                        
#5  0x590bea231eba in field_map_get_offset+46                                                                                                      
#6  0x590bea23242a in tuple_field_raw_by_path+417                                                                                                  
#7  0x590bea23282b in tuple_field_raw_by_part+203                                                                                                  
#8  0x590bea23288c in tuple_field_by_part+91                                                                                                       
#9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103                                                  
#10 0x590be9d4fba3 in tuple_hint+40                                                                                                                
#11 0x590be9d50acf in vy_stmt_hint+178                                                                                                             
#12 0x590be9d53531 in vy_page_stmt+168                                                                                                             
#13 0x590be9d535ea in vy_page_find_key+142                                                                                                         
#14 0x590be9d545e6 in vy_page_read_cb+210                                                                                                          
#15 0x590be9f94ef0 in cbus_call_perform+44                                                                                                         
#16 0x590be9f94eae in cmsg_deliver+52                                                                                                              
#17 0x590be9f9583e in cbus_process+100                                                                                                             
#18 0x590be9f958a5 in cbus_loop+28                                                                                                                 
#19 0x590be9d512da in vy_run_reader_f+381                                                                                                          
#20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34                                                                 
#21 0x590be9f8b697 in fiber_loop+219                                     
#22 0x590bea374bb6 in coro_init+120                                      
Aborted (core dumped)

coredump and atarntool binary: gh-10123-core.zip

#0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=126103687525952) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=6, threadid=126103687525952) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=126103687525952, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
#3  0x000072b111642476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
#4  0x000072b1116287f3 in __GI_abort () at ./stdlib/abort.c:79
#5  0x0000590be9f7f652 in crash_signal_cb (signo=11, siginfo=0x72b0c000e430, context=0x72b0c000e300)
    at /home/sergeyb/sources/MRG/tarantool/src/lib/core/crash.c:203
#6  <signal handler called>
#7  0x0000590bea385e3c in load_u32 (p=0x72b2c00266e8) at /home/sergeyb/sources/MRG/tarantool/src/lib/bit/bit.h:83
#8  0x0000590bea231eba in field_map_get_offset (field_map=0x72b0c00266ec, offset_slot=2147483647, multikey_idx=-1)
    at /home/sergeyb/sources/MRG/tarantool/src/box/field_map.h:164
#9  0x0000590bea23242a in tuple_field_raw_by_path (format=0x590bec25e2b0, tuple=0x72b0c00266ec "\225\302", <incomplete sequence \317>, 
    field_map=0x72b0c00266ec, fieldno=1, path=0x0, path_len=0, index_base=1, offset_slot_hint=0x590bec0ef9e8, multikey_idx=-1)
    at /home/sergeyb/sources/MRG/tarantool/src/box/tuple.h:988
#10 0x0000590bea23282b in tuple_field_raw_by_part (format=0x590bec25e2b0, data=0x72b0c00266ec "\225\302", <incomplete sequence \317>, 
    field_map=0x72b0c00266ec, part=0x590bec0ef9a8, multikey_idx=-1) at /home/sergeyb/sources/MRG/tarantool/src/box/tuple.h:1118
#11 0x0000590bea23288c in tuple_field_by_part (tuple=0x72b0c00266d0, part=0x590bec0ef9a8, multikey_idx=-1)
    at /home/sergeyb/sources/MRG/tarantool/src/box/tuple.h:1135
#12 0x0000590bea24cd2d in tuple_hint<(field_type)5, false, false> (tuple=0x72b0c00266d0, key_def=0x590bec0ef930)
    at /home/sergeyb/sources/MRG/tarantool/src/box/tuple_compare.cc:2073
#13 0x0000590be9d4fba3 in tuple_hint (tuple=0x72b0c00266d0, key_def=0x590bec0ef930) at /home/sergeyb/sources/MRG/tarantool/src/box/key_def.h:1168
#14 0x0000590be9d50acf in vy_stmt_hint (stmt=0x72b0c00266d0, key_def=0x590bec0ef930) at /home/sergeyb/sources/MRG/tarantool/src/box/vy_stmt.h:397
#15 0x0000590be9d53531 in vy_page_stmt (page=0x590bec47b1c0, stmt_no=0, cmp_def=0x590bec0ef930, format=0x590bec25e2b0)
    at /home/sergeyb/sources/MRG/tarantool/src/box/vy_run.c:787
#16 0x0000590be9d535ea in vy_page_find_key (page=0x590bec47b1c0, key=..., cmp_def=0x590bec0ef930, format=0x590bec25e2b0, iterator_type=ITER_GT, 
    equal_key=0x72b083051ae4) at /home/sergeyb/sources/MRG/tarantool/src/box/vy_run.c:811
#17 0x0000590be9d545e6 in vy_page_read_cb (base=0x72b083051a48) at /home/sergeyb/sources/MRG/tarantool/src/box/vy_run.c:992
#18 0x0000590be9f94ef0 in cbus_call_perform (m=0x72b083051a48) at /home/sergeyb/sources/MRG/tarantool/src/lib/core/cbus.c:364
#19 0x0000590be9f94eae in cmsg_deliver (msg=0x72b083051a48) at /home/sergeyb/sources/MRG/tarantool/src/lib/core/cbus.c:350
#20 0x0000590be9f9583e in cbus_process (endpoint=0x72b0cc980d50) at /home/sergeyb/sources/MRG/tarantool/src/lib/core/cbus.c:601
#21 0x0000590be9f958a5 in cbus_loop (endpoint=0x72b0cc980d50) at /home/sergeyb/sources/MRG/tarantool/src/lib/core/cbus.c:608
#22 0x0000590be9d512da in vy_run_reader_f (ap=0x72b0cc810278) at /home/sergeyb/sources/MRG/tarantool/src/box/vy_run.c:132
#23 0x0000590be9cb4147 in fiber_cxx_invoke(fiber_func, typedef __va_list_tag __va_list_tag *) (f=0x590be9d5115d <vy_run_reader_f>, 
    ap=0x72b0cc810278) at /home/sergeyb/sources/MRG/tarantool/src/lib/core/fiber.h:1308
#24 0x0000590be9f8b697 in fiber_loop (data=0x0) at /home/sergeyb/sources/MRG/tarantool/src/lib/core/fiber.c:1153
#25 0x0000590bea374bb6 in coro_init () at /home/sergeyb/sources/MRG/tarantool/third_party/coro/coro.c:108
(gdb)

Expected behavior

no crash
@ligurio ligurio added the bug Something isn't working label Jun 10, 2024
@locker locker self-assigned this Jun 10, 2024
@locker locker added 2.11 Target is 2.11 and all newer release/master branches 3.1 Target is 3.1 and all newer release/master branches labels Jun 10, 2024
locker added a commit to locker/tarantool that referenced this issue Jun 10, 2024
@locker
tuple: don't use offset_slot_cache in vinyl threads
02f2ed5 
`key_part::offset_slot_cache` and `key_part::format_epoch` are used for
speeding up tuple field lookup in `tuple_field_raw_by_part()`. These
structure members are accessed and updated without any locks, assuming
this code is executed exclusively in the tx thread. However, this isn't
necessarily true because we also perform tuple field lookups in vinyl
read threads. Apparently, this can result in unexpected races and bugs,
for example:

```
  tarantool#1  0x590be9f7eb6d in crash_collect+256
  tarantool#2  0x590be9f7f5a9 in crash_signal_cb+100
  tarantool#3  0x72b111642520 in __sigaction+80
  tarantool#4  0x590bea385e3c in load_u32+35
  tarantool#5  0x590bea231eba in field_map_get_offset+46
  tarantool#6  0x590bea23242a in tuple_field_raw_by_path+417
  tarantool#7  0x590bea23282b in tuple_field_raw_by_part+203
  tarantool#8  0x590bea23288c in tuple_field_by_part+91
  tarantool#9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103
  tarantool#10 0x590be9d4fba3 in tuple_hint+40
  tarantool#11 0x590be9d50acf in vy_stmt_hint+178
  tarantool#12 0x590be9d53531 in vy_page_stmt+168
  tarantool#13 0x590be9d535ea in vy_page_find_key+142
  tarantool#14 0x590be9d545e6 in vy_page_read_cb+210
  tarantool#15 0x590be9f94ef0 in cbus_call_perform+44
  tarantool#16 0x590be9f94eae in cmsg_deliver+52
  tarantool#17 0x590be9f9583e in cbus_process+100
  tarantool#18 0x590be9f958a5 in cbus_loop+28
  tarantool#19 0x590be9d512da in vy_run_reader_f+381
  tarantool#20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
  tarantool#21 0x590be9f8b697 in fiber_loop+219
  tarantool#22 0x590bea374bb6 in coro_init+120
```

Fix this by skipping this optimization for threads other than tx.

No test is added because reproducing this race is tricky. Ideally, bugs
like this one should be caught by fuzzing tests or thread sanitizers.

Closes tarantool#10123

NO_DOC=bug fix
NO_TEST=tested manually with fuzzer
@locker locker mentioned this issue Jun 10, 2024
Merged
locker added a commit to locker/tarantool that referenced this issue Jun 11, 2024
@locker
tuple: don't use offset_slot_cache in vinyl threads
2563690 
`key_part::offset_slot_cache` and `key_part::format_epoch` are used for
speeding up tuple field lookup in `tuple_field_raw_by_part()`. These
structure members are accessed and updated without any locks, assuming
this code is executed exclusively in the tx thread. However, this isn't
necessarily true because we also perform tuple field lookups in vinyl
read threads. Apparently, this can result in unexpected races and bugs,
for example:

```
  tarantool#1  0x590be9f7eb6d in crash_collect+256
  tarantool#2  0x590be9f7f5a9 in crash_signal_cb+100
  tarantool#3  0x72b111642520 in __sigaction+80
  tarantool#4  0x590bea385e3c in load_u32+35
  tarantool#5  0x590bea231eba in field_map_get_offset+46
  tarantool#6  0x590bea23242a in tuple_field_raw_by_path+417
  tarantool#7  0x590bea23282b in tuple_field_raw_by_part+203
  tarantool#8  0x590bea23288c in tuple_field_by_part+91
  tarantool#9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103
  tarantool#10 0x590be9d4fba3 in tuple_hint+40
  tarantool#11 0x590be9d50acf in vy_stmt_hint+178
  tarantool#12 0x590be9d53531 in vy_page_stmt+168
  tarantool#13 0x590be9d535ea in vy_page_find_key+142
  tarantool#14 0x590be9d545e6 in vy_page_read_cb+210
  tarantool#15 0x590be9f94ef0 in cbus_call_perform+44
  tarantool#16 0x590be9f94eae in cmsg_deliver+52
  tarantool#17 0x590be9f9583e in cbus_process+100
  tarantool#18 0x590be9f958a5 in cbus_loop+28
  tarantool#19 0x590be9d512da in vy_run_reader_f+381
  tarantool#20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
  tarantool#21 0x590be9f8b697 in fiber_loop+219
  tarantool#22 0x590bea374bb6 in coro_init+120
```

Fix this by skipping this optimization for threads other than tx.

No test is added because reproducing this race is tricky. Ideally, bugs
like this one should be caught by fuzzing tests or thread sanitizers.

Closes tarantool#10123

NO_DOC=bug fix
NO_TEST=tested manually with fuzzer
locker added a commit that referenced this issue Jun 13, 2024
@locker
tuple: don't use offset_slot_cache in vinyl threads
19d1f1c 
`key_part::offset_slot_cache` and `key_part::format_epoch` are used for
speeding up tuple field lookup in `tuple_field_raw_by_part()`. These
structure members are accessed and updated without any locks, assuming
this code is executed exclusively in the tx thread. However, this isn't
necessarily true because we also perform tuple field lookups in vinyl
read threads. Apparently, this can result in unexpected races and bugs,
for example:

```
  #1  0x590be9f7eb6d in crash_collect+256
  #2  0x590be9f7f5a9 in crash_signal_cb+100
  #3  0x72b111642520 in __sigaction+80
  #4  0x590bea385e3c in load_u32+35
  #5  0x590bea231eba in field_map_get_offset+46
  #6  0x590bea23242a in tuple_field_raw_by_path+417
  #7  0x590bea23282b in tuple_field_raw_by_part+203
  #8  0x590bea23288c in tuple_field_by_part+91
  #9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103
  #10 0x590be9d4fba3 in tuple_hint+40
  #11 0x590be9d50acf in vy_stmt_hint+178
  #12 0x590be9d53531 in vy_page_stmt+168
  #13 0x590be9d535ea in vy_page_find_key+142
  #14 0x590be9d545e6 in vy_page_read_cb+210
  #15 0x590be9f94ef0 in cbus_call_perform+44
  #16 0x590be9f94eae in cmsg_deliver+52
  #17 0x590be9f9583e in cbus_process+100
  #18 0x590be9f958a5 in cbus_loop+28
  #19 0x590be9d512da in vy_run_reader_f+381
  #20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
  #21 0x590be9f8b697 in fiber_loop+219
  #22 0x590bea374bb6 in coro_init+120
```

Fix this by skipping this optimization for threads other than tx.

No test is added because reproducing this race is tricky. Ideally, bugs
like this one should be caught by fuzzing tests or thread sanitizers.

Closes #10123

NO_DOC=bug fix
NO_TEST=tested manually with fuzzer
locker added a commit that referenced this issue Jun 13, 2024
@locker
tuple: don't use offset_slot_cache in vinyl threads
084865a 
`key_part::offset_slot_cache` and `key_part::format_epoch` are used for
speeding up tuple field lookup in `tuple_field_raw_by_part()`. These
structure members are accessed and updated without any locks, assuming
this code is executed exclusively in the tx thread. However, this isn't
necessarily true because we also perform tuple field lookups in vinyl
read threads. Apparently, this can result in unexpected races and bugs,
for example:

```
  #1  0x590be9f7eb6d in crash_collect+256
  #2  0x590be9f7f5a9 in crash_signal_cb+100
  #3  0x72b111642520 in __sigaction+80
  #4  0x590bea385e3c in load_u32+35
  #5  0x590bea231eba in field_map_get_offset+46
  #6  0x590bea23242a in tuple_field_raw_by_path+417
  #7  0x590bea23282b in tuple_field_raw_by_part+203
  #8  0x590bea23288c in tuple_field_by_part+91
  #9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103
  #10 0x590be9d4fba3 in tuple_hint+40
  #11 0x590be9d50acf in vy_stmt_hint+178
  #12 0x590be9d53531 in vy_page_stmt+168
  #13 0x590be9d535ea in vy_page_find_key+142
  #14 0x590be9d545e6 in vy_page_read_cb+210
  #15 0x590be9f94ef0 in cbus_call_perform+44
  #16 0x590be9f94eae in cmsg_deliver+52
  #17 0x590be9f9583e in cbus_process+100
  #18 0x590be9f958a5 in cbus_loop+28
  #19 0x590be9d512da in vy_run_reader_f+381
  #20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
  #21 0x590be9f8b697 in fiber_loop+219
  #22 0x590bea374bb6 in coro_init+120
```

Fix this by skipping this optimization for threads other than tx.

No test is added because reproducing this race is tricky. Ideally, bugs
like this one should be caught by fuzzing tests or thread sanitizers.

Closes #10123

NO_DOC=bug fix
NO_TEST=tested manually with fuzzer

(cherry picked from commit 19d1f1c)
locker added a commit that referenced this issue Jun 13, 2024
@locker
tuple: don't use offset_slot_cache in vinyl threads
7d90a94 
`key_part::offset_slot_cache` and `key_part::format_epoch` are used for
speeding up tuple field lookup in `tuple_field_raw_by_part()`. These
structure members are accessed and updated without any locks, assuming
this code is executed exclusively in the tx thread. However, this isn't
necessarily true because we also perform tuple field lookups in vinyl
read threads. Apparently, this can result in unexpected races and bugs,
for example:

```
  #1  0x590be9f7eb6d in crash_collect+256
  #2  0x590be9f7f5a9 in crash_signal_cb+100
  #3  0x72b111642520 in __sigaction+80
  #4  0x590bea385e3c in load_u32+35
  #5  0x590bea231eba in field_map_get_offset+46
  #6  0x590bea23242a in tuple_field_raw_by_path+417
  #7  0x590bea23282b in tuple_field_raw_by_part+203
  #8  0x590bea23288c in tuple_field_by_part+91
  #9  0x590bea24cd2d in unsigned long tuple_hint<(field_type)5, false, false>(tuple*, key_def*)+103
  #10 0x590be9d4fba3 in tuple_hint+40
  #11 0x590be9d50acf in vy_stmt_hint+178
  #12 0x590be9d53531 in vy_page_stmt+168
  #13 0x590be9d535ea in vy_page_find_key+142
  #14 0x590be9d545e6 in vy_page_read_cb+210
  #15 0x590be9f94ef0 in cbus_call_perform+44
  #16 0x590be9f94eae in cmsg_deliver+52
  #17 0x590be9f9583e in cbus_process+100
  #18 0x590be9f958a5 in cbus_loop+28
  #19 0x590be9d512da in vy_run_reader_f+381
  #20 0x590be9cb4147 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*)+34
  #21 0x590be9f8b697 in fiber_loop+219
  #22 0x590bea374bb6 in coro_init+120
```

Fix this by skipping this optimization for threads other than tx.

No test is added because reproducing this race is tricky. Ideally, bugs
like this one should be caught by fuzzing tests or thread sanitizers.

Closes #10123

NO_DOC=bug fix
NO_TEST=tested manually with fuzzer

(cherry picked from commit 19d1f1c)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@locker locker

Labels
2.11 Target is 2.11 and all newer release/master branches 3.1 Target is 3.1 and all newer release/master branches bug Something isn't working crash vinyl
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

tuple: don't use offset_slot_cache in vinyl threads locker/tarantool
2 participants
@locker @ligurio