Fix gcc 4.7 warnings with enabled -Wall by rtsisyk · Pull Request #8 · tarantool/tarantool

rtsisyk · 2012-11-08T11:36:01Z

I usually use -Wall -Werror during development and I would like to make it work without these warnings. I have no idea how to fix libev, it seems that their code ...hmm.. is not so good.

* Fix #1 - add documentation * Fix #2 - update the list of supported distros * Fix #3 - don't clone repository three times and allow in-place builds * Fix #4 - rewrite all rules using GNU `make` instead of shell scripts * Fix #8 - allow to override steps of build process * Rework Docker images

Engine callbacks that perform garbage collection may sleep, because they use coio for removing files to avoid blocking the TX thread. If garbage collection is called concurrently from different fibers (e.g. from relay fibers), we may attempt to delete the same file multiple times. What is worse xdir_collect_garbage(), used by engine callbacks to remove files, isn't safe against concurrent execution - it first unlinks a file via coio, which involves a yield, and only then removes the corresponding vclock from the directory index. This opens a race window for another fiber to read the same clock and yield, in the interim the vclock can be freed by the first fiber: #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007f105ceda3fa in __GI_abort () at abort.c:89 #2 0x000055e4c03f4a3d in sig_fatal_cb (signo=11) at main.cc:184 #3 <signal handler called> #4 0x000055e4c066907a in vclockset_remove (rbtree=0x55e4c1010e58, node=0x55e4c1023d20) at box/vclock.c:215 #5 0x000055e4c06256af in xdir_collect_garbage (dir=0x55e4c1010e28, signature=342, use_coio=true) at box/xlog.c:620 #6 0x000055e4c0417dcc in memtx_engine_collect_garbage (engine=0x55e4c1010df0, lsn=342) at box/memtx_engine.c:784 #7 0x000055e4c0414dbf in engine_collect_garbage (lsn=342) at box/engine.c:155 #8 0x000055e4c04a36c7 in gc_run () at box/gc.c:192 #9 0x000055e4c04a38f2 in gc_consumer_advance (consumer=0x55e4c1021360, signature=342) at box/gc.c:262 #10 0x000055e4c04b4da8 in tx_gc_advance (msg=0x7f1028000aa0) at box/relay.cc:250 #11 0x000055e4c04eb854 in cmsg_deliver (msg=0x7f1028000aa0) at cbus.c:353 #12 0x000055e4c04ec871 in fiber_pool_f (ap=0x7f1056800ec0) at fiber_pool.c:64 #13 0x000055e4c03f4784 in fiber_cxx_invoke(fiber_func, typedef __va_list_tag __va_list_tag *) (f=0x55e4c04ec6d4 <fiber_pool_f>, ap=0x7f1056800ec0) at fiber.h:665 #14 0x000055e4c04e6816 in fiber_loop (data=0x0) at fiber.c:631 #15 0x000055e4c0687dab in coro_init () at /home/vlad/src/tarantool/third_party/coro/coro.c:110 Fix this by serializing concurrent execution of garbage collection callbacks with a latch.

There's no check that range->begin can be NULL (for the leftmost range) in vy_read_iterator_next_range(), which leads to a crash when trying to compare range->begin to last_stmt. Add it. #0 0x5621e45fc1b1 in print_backtrace+9 #1 0x5621e4507b9f in _ZL12sig_fatal_cbi+e2 #2 0x7f819188c0c0 in __restore_rt+0 #3 0x5621e456e34b in tuple_data+c #4 0x5621e456e814 in vy_tuple_compare_with_key+20 #5 0x5621e4570cec in vy_read_iterator_next_range+139 #6 0x5621e456fd87 in vy_read_iterator_next_key+275 #7 0x5621e45710ad in vy_read_iterator_next+22c #8 0x5621e453db42 in vinyl_iterator_next+19a #9 0x5621e4513772 in iterator_next+cb #10 0x5621e45afe4a in box_select+32d #11 0x5621e45d4beb in _ZL11lbox_selectP9lua_State+187 #12 0x5621e461c96b in lj_BC_FUNCC+34 #13 0x5621e463f4e3 in lua_pcall+18e #14 0x5621e45e870c in luaT_call+29 #15 0x5621e45e1ad7 in lua_fiber_run_f+c0 #16 0x5621e4507914 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e #17 0x5621e45f9ba1 in fiber_loop+82 #18 0x5621e479b31b in coro_init+4c Fixes 5e414a7 ("vinyl: read iterator: do not reopen all sources when range is changed") Closes #2990

say_logger_init() zeroes the default logger object (log_default) before proceeding to logging subsystem configuration. If configuration fails for some reason (e.g. error opening the log file), the default logger will be left uninitialized, and we will crash trying to print the error to the console: #0 0x564065001af5 in print_backtrace+9 #1 0x564064f0b17f in _ZL12sig_fatal_cbi+e2 #2 0x7ff94519f0c0 in __restore_rt+0 #3 (nil) in +0 #4 0x564064ffc399 in say_default+d2 #5 0x564065011c37 in _ZNK11SystemError3logEv+6d #6 0x5640650117be in exception_log+3d #7 0x564064ff9750 in error_log+1d #8 0x564064ff9847 in diag_log+50 #9 0x564064ffab9b in say_logger_init+22a #10 0x564064f0bffb in load_cfg+69a #11 0x564064fd2f49 in _ZL13lbox_cfg_loadP9lua_State+12 #12 0x56406502258b in lj_BC_FUNCC+34 #13 0x564065045103 in lua_pcall+18e #14 0x564064fed733 in luaT_call+29 #15 0x564064fe5536 in lua_main+b9 #16 0x564064fe5d74 in run_script_f+7b5 #17 0x564064f0aef4 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e #18 0x564064fff4e5 in fiber_loop+82 #19 0x5640651a123b in coro_init+4c #20 (nil) in +4c Fix this by making say_logger_init() initialize the default logger object first and only assign it to log_default on success. See #3048

If a fiber waiting for a read task to complete is cancelled, it will leave the read iterator immediately, leaving the read task pending. If the index is dropped before the read task is complete, the task will attempt to dereference a deleted run upon completion: #0 0x560b4007dbbc in print_backtrace+9 #1 0x560b3ff80a1d in _ZL12sig_fatal_cbiP9siginfo_tPv+1e7 #2 0x7f52b09190c0 in __restore_rt+0 #3 0x7f52af6ea30a in bzero+5a #4 0x560b3ffc7a99 in mempool_free+2a #5 0x560b3ffcaeb7 in vy_page_read_cb_free+47 #6 0x560b400806a2 in cbus_call_done+3f #7 0x560b400805ea in cmsg_deliver+30 #8 0x560b40080e4b in cbus_process+51 #9 0x560b4003046b in _ZL10tx_prio_cbP7ev_loopP10ev_watcheri+2b #10 0x560b4023d86e in ev_invoke_pending+ca #11 0x560b4023e772 in ev_run+5a0 #12 0x560b3ff822dc in main+5ed #13 0x7f52af6862b1 in __libc_start_main+f1 #14 0x560b3ff801da in _start+2a #15 (nil) in +2a Fix this by elevating the run reference counter per each read task. Note, currently we use vy_run::refs not only as a reference counter, but also as a counter of slices created for the run - see how we compare it to vy_run::compacted_slice_count in vy_task_compact_complete(). This isn't going to work anymore, obviously. Now we need to count slices created per each run in a separate counter, vy_run::slice_count. Anyway, it was a rather dubious hack to abuse reference counter for counting slices and it's good to finally get rid of it.

`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)

The issue is we increment `page_count` only on page write. If we fail for some reason before then page info `min_key` in leaked. LSAN report for 'vinyl/recovery_quota.test.lua': ``` 2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf) ================================================================= ==478603==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974) tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14 tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23 tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6 tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6 tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8 tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9 tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6 tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10 tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18 tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ``` NO_TEST=covered by existing tests (ASAN build) NO_DOC=bugfix

Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option. ``` [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua [ pass ] [050] [050] [050] [Instance "box" returns with non-zero exit code: 1] [050] [050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log: [050] tarantool#9 0x55d6c6868851 (<unknown module>) [050] [050] Direct leak of 342 byte(s) in 5 object(s) allocated from: [050] #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa) [050] tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24 [050] tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5 [050] tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27 [050] tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9 [050] tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22 [050] tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12 [050] tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9 [050] tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11 [050] tarantool#9 0x55d6c685ea09 (<unknown module>) [050] [050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s). [055] box-luatest/gh_8530_alter_space_snapshot_test.> [ pass ] ``` 1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431 2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags NO_CHANGELOG=internal NO_DOC=internal NO_TEST=internal

The issue is we increment `page_count` only on page write. If we fail for some reason before then page info `min_key` in leaked. LSAN report for 'vinyl/recovery_quota.test.lua': ``` 2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf) ================================================================= ==478603==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974) tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14 tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23 tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6 tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6 tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8 tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9 tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6 tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10 tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18 tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ``` NO_TEST=covered by existing tests (ASAN build) NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail for some reason before then page info `min_key` in leaked. LSAN report for 'vinyl/recovery_quota.test.lua': ``` 2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf) ================================================================= ==478603==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974) tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14 tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23 tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6 tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6 tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8 tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9 tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6 tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10 tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18 tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ``` Closes tarantool#10489 Part-of tarantool#10211 NO_TEST=covered by existing tests NO_DOC=bugfix

Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option. ``` [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua [ pass ] [050] [050] [050] [Instance "box" returns with non-zero exit code: 1] [050] [050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log: [050] tarantool#9 0x55d6c6868851 (<unknown module>) [050] [050] Direct leak of 342 byte(s) in 5 object(s) allocated from: [050] #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa) [050] tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24 [050] tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5 [050] tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27 [050] tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9 [050] tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22 [050] tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12 [050] tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9 [050] tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11 [050] tarantool#9 0x55d6c685ea09 (<unknown module>) [050] [050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s). [055] box-luatest/gh_8530_alter_space_snapshot_test.> [ pass ] ``` 1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431 2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags NO_CHANGELOG=internal NO_DOC=internal NO_TEST=internal

The issue is we increment `page_count` only on page write. If we fail for some reason before then page info `min_key` in leaked. LSAN report for 'vinyl/recovery_quota.test.lua': ``` 2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf) ================================================================= ==478603==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974) tarantool#1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14 tarantool#2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23 tarantool#3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6 tarantool#4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6 tarantool#5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8 tarantool#6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9 tarantool#7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6 tarantool#8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10 tarantool#9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18 tarantool#10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ``` Closes tarantool#10489 Part-of tarantool#10211 NO_TEST=covered by existing tests NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail for some reason before then page info `min_key` in leaked. LSAN report for 'vinyl/recovery_quota.test.lua': ``` 2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf) ================================================================= ==478603==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974) #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14 #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23 #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6 #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6 #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8 #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9 #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6 #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10 #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18 #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ``` Closes #10489 Part-of #10211 NO_TEST=covered by existing tests NO_DOC=bugfix

The issue is we increment `page_count` only on page write. If we fail for some reason before then page info `min_key` in leaked. LSAN report for 'vinyl/recovery_quota.test.lua': ``` 2024-07-05 13:30:34.605 [478603] main/103/on_shutdown vy_scheduler.c:1668 E> 512/0: failed to compact range (-inf..inf) ================================================================= ==478603==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x5e4ebafcae09 in malloc (/home/shiny/dev/tarantool/build-asan-debug/src/tarantool+0x1244e09) (BuildId: 20c5933d67a3831c4f43f6860379d58d35b81974) #1 0x5e4ebb3f9b69 in vy_key_dup /home/shiny/dev/tarantool/src/box/vy_stmt.c:308:14 #2 0x5e4ebb49b615 in vy_page_info_create /home/shiny/dev/tarantool/src/box/vy_run.c:257:23 #3 0x5e4ebb48f59f in vy_run_writer_start_page /home/shiny/dev/tarantool/src/box/vy_run.c:2196:6 #4 0x5e4ebb48c6b6 in vy_run_writer_append_stmt /home/shiny/dev/tarantool/src/box/vy_run.c:2287:6 #5 0x5e4ebb72877f in vy_task_write_run /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1132:8 #6 0x5e4ebb73305e in vy_task_compaction_execute /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1485:9 #7 0x5e4ebb73e152 in vy_task_f /home/shiny/dev/tarantool/src/box/vy_scheduler.c:1795:6 #8 0x5e4ebb01e0b1 in fiber_cxx_invoke(int (*)(__va_list_tag*), __va_list_tag*) /home/shiny/dev/tarantool/src/lib/core/fiber.h:1331:10 #9 0x5e4ebc389ee0 in fiber_loop /home/shiny/dev/tarantool/src/lib/core/fiber.c:1182:18 #10 0x5e4ebd3e9595 in coro_init /home/shiny/dev/tarantool/third_party/coro/coro.c:108:3 SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s). ``` Closes #10489 Part-of #10211 NO_TEST=covered by existing tests NO_DOC=bugfix (cherry picked from commit 84101f6)

Crash the program after printing the first error report (WARNING: USE AT YOUR OWN RISK!). The flag has effect only if code was compiled with -fsanitize-recover=address compile option. ``` [061] replication/tarantoolgh-5430-cluster-mvcc.test.lua [ pass ] [050] [050] [050] [Instance "box" returns with non-zero exit code: 1] [050] [050] [test-run server "box"] Last 15 lines of the log file /tmp/t/050_box/box.log: [050] tarantool#9 0x55d6c6868851 (<unknown module>) [050] [050] Direct leak of 342 byte(s) in 5 object(s) allocated from: [050] #0 0x55d69b184cae in malloc (/__w/tarantool/tarantool/src/tarantool+0x1268cae) (BuildId: 4f3fed4334a726219fb69119e67d451f0cb1ccfa) [050] tarantool#1 0x55d69d50040c in small_asan_alloc /__w/tarantool/tarantool/src/lib/small/small/util.c:94:24 [050] tarantool#2 0x55d69d4fcb3c in smalloc /__w/tarantool/tarantool/src/lib/small/small/small_asan.c:57:5 [050] tarantool#3 0x55d69ce3782f in runtime_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:138:27 [050] tarantool#4 0x55d69ce33fac in tuple_new /__w/tarantool/tarantool/src/box/tuple.h:801:9 [050] tarantool#5 0x55d69ce34844 in box_tuple_new /__w/tarantool/tarantool/src/box/tuple.c:845:22 [050] tarantool#6 0x55d69b523021 in session_settings_index_get /__w/tarantool/tarantool/src/box/session_settings.c:261:12 [050] tarantool#7 0x55d69b284077 in index_get(index*, char const*, unsigned int, tuple**) /__w/tarantool/tarantool/src/box/index.h:909:9 [050] tarantool#8 0x55d69b282794 in box_index_get /__w/tarantool/tarantool/src/box/index.cc:390:11 [050] tarantool#9 0x55d6c685ea09 (<unknown module>) [050] [050] SUMMARY: AddressSanitizer: 5627 byte(s) leaked in 83 allocation(s). [055] box-luatest/gh_8530_alter_space_snapshot_test.> [ pass ] ``` 1. https://github.com/tarantool/tarantool/actions/runs/10454868034/job/28948757147?pr=10431 2. https://github.com/google/sanitizers/wiki/AddressSanitizerFlags NO_CHANGELOG=internal NO_DOC=internal NO_TEST=internal

The reason is that the previous libcurl submodule update in commit 0919f39 ("third_party: update libcurl from 8.8.0 to 8.10.1") reveals the following regression: NOWRAP ```c $ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()" tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed. Aborted (core dumped) ``` NOWRAP The stacktrace is the following: NOWRAP ```c <...> #4 __assert_fail #5 curl_multi_assign // <- called by us #6 curl_multi_sock_cb // <- this is our callback #7 Curl_multi_pollset_ev #8 cpool_update_shutdown_ev #9 cpool_discard_conn #10 cpool_close_and_destroy_all #11 Curl_cpool_destroy #12 curl_multi_cleanup #13 curl_env_finish // <- destroy the multi handle #14 httpc_env_finish #15 luaT_httpc_cleanup #16 lj_BC_FUNCC #17 gc_call_finalizer #18 gc_finalize #19 gc_onestep #20 lj_gc_fullgc #21 lua_gc #22 lj_cf_collectgarbage #23 lj_BC_FUNCC #24 lua_pcall #25 luaT_call #26 lua_main #27 run_script_f #28 fiber_cxx_invoke #29 fiber_loop #30 coro_init ``` NOWRAP The multi handle is during the destroy, but our `CURLMOPT_SOCKETFUNCTION` callback is invoked and the `curl_multi_assign()` call (invoked to associate a libev watcher to the given file descriptor) fails on the assertion. Everything is as described in curl/curl#15201. The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit updates libcurl to this revision to fix the regression. Adjusted build options in our build script: * Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3] * Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4] * Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`: [curl-8_10_1-130-gd78e129d5][5] [1]: curl/curl@48f61e7 [2]: curl/curl@461ce6c [3]: curl/curl@ce7d0d4 [4]: curl/curl@71cf0d1 [5]: curl/curl@d78e129 NO_DOC=bugfix NO_CHANGELOG=fixes an unreleased commit NO_TEST=can't reproduce without https to add a test case, verified locally

The reason is that the previous libcurl submodule update in commit 0919f39 ("third_party: update libcurl from 8.8.0 to 8.10.1") reveals the following regression: NOWRAP ```c $ tarantool -e "require('http.client').new():get('https://google.com') collectgarbage()" tarantool: ./third_party/curl/lib/multi.c:3691: curl_multi_assign: Assertion `!(multi)' failed. Aborted (core dumped) ``` NOWRAP The stacktrace is the following: NOWRAP ```c <...> #4 __assert_fail #5 curl_multi_assign // <- called by us #6 curl_multi_sock_cb // <- this is our callback #7 Curl_multi_pollset_ev #8 cpool_update_shutdown_ev #9 cpool_discard_conn #10 cpool_close_and_destroy_all #11 Curl_cpool_destroy #12 curl_multi_cleanup #13 curl_env_finish // <- destroy the multi handle #14 httpc_env_finish #15 luaT_httpc_cleanup #16 lj_BC_FUNCC #17 gc_call_finalizer #18 gc_finalize #19 gc_onestep #20 lj_gc_fullgc #21 lua_gc #22 lj_cf_collectgarbage #23 lj_BC_FUNCC #24 lua_pcall #25 luaT_call #26 lua_main #27 run_script_f #28 fiber_cxx_invoke #29 fiber_loop #30 coro_init ``` NOWRAP The multi handle is during the destroy, but our `CURLMOPT_SOCKETFUNCTION` callback is invoked and the `curl_multi_assign()` call (invoked to associate a libev watcher to the given file descriptor) fails on the assertion. Everything is as described in curl/curl#15201. The first bad libcurl's commit is [curl-8_10_0-4-g48f61e781][1], but later it was fixed in [curl-8_10_1-241-g461ce6c61][2]. This commit updates libcurl to this revision to fix the regression. Adjusted build options in our build script: * Added `CURL_DISABLE_IPFS=ON`: [curl-8_10_1-57-gce7d0d413][3] * Added `CURL_TEST_BUNDLES=OFF`: [curl-8_10_1-67-g71cf0d1fc][4] * Changed `ENABLE_WEBSOCKETS=OFF` to `CURL_DISABLE_WEBSOCKETS=ON`: [curl-8_10_1-130-gd78e129d5][5] [1]: curl/curl@48f61e7 [2]: curl/curl@461ce6c [3]: curl/curl@ce7d0d4 [4]: curl/curl@71cf0d1 [5]: curl/curl@d78e129 NO_DOC=bugfix NO_CHANGELOG=fixes an unreleased commit NO_TEST=can't reproduce without https to add a test case, verified locally (cherry picked from commit fbe6d0a)

Fix gcc 4.7 warnings with enabled -Wall

aba21a5

kostja merged commit aba21a5 into master Nov 20, 2012

pgulutzan mentioned this pull request Apr 25, 2014

Sophia: crash if insert without index #280

Closed

knizhnik mentioned this pull request Apr 27, 2014

Grow slab_alloc_arena without server restart. #284

Closed

kostja mentioned this pull request Jun 18, 2014

title() tries to access Lua and leads to a crash #352

Closed

vocalbit mentioned this pull request Jun 29, 2014

Crash on insert() for sophia space without index #365

Closed

kostja mentioned this pull request Sep 5, 2014

1.6.3 crash CentOS release 5.4 #489

Closed

pmwkaa mentioned this pull request Sep 17, 2014

sophia: crash on memory free (disk write error) #511

Closed

ilejn mentioned this pull request Nov 6, 2014

Binary protocol - abnormal termination #615

Closed

pgulutzan mentioned this pull request Dec 12, 2014

Segmentation fault if inappropriate function used for trigger #656

Closed

pmwkaa mentioned this pull request Feb 4, 2015

catch exceptions in boxffi_iterator_next #708

Closed

zloidemon added a commit that referenced this pull request Mar 24, 2015

Translated screen #8 to Russian

edc78a4

YadrovSergey mentioned this pull request Feb 8, 2016

Segmentation fault #1319

Closed

kostja mentioned this pull request Feb 10, 2016

Crash at lj_tab_newkey() (Tarantool 1.5) #828

Closed

This was referenced Jun 7, 2016

lj segfault with test script #1528

Closed

phia: segfault in lj (possibly caused by compressed reads fail) #1531

Closed

andrew-statsenko mentioned this pull request Nov 8, 2016

vinyl: slow start from xlogs #1900

Closed

GeorgyKirichenko mentioned this pull request Nov 21, 2016

box-py/space_crash.test.py crashes server on Travis CI #1667

Closed

aleksej-paschenko mentioned this pull request May 30, 2017

vinyl: Tarantool crashes during transaction #2487

Closed

Gerold103 mentioned this pull request Jul 27, 2017

vinyl: le/lt iterator crashes in vy_mem_iterator_restore #2614

Closed

llelik8 pushed a commit that referenced this pull request Feb 21, 2018

Fix #8: Update msgpack.decode description

400deb5

KseniyaYakil mentioned this pull request Apr 17, 2018

tarantool cores #3352

Closed

vvzvlad mentioned this pull request Apr 27, 2018

Segmentation fault(error message requests create issue) #3386

Closed

alekseyxxx mentioned this pull request Jun 14, 2018

Module 'http.client': request fails with tarantool crash while running in docker #3454

Closed

d-enk mentioned this pull request Aug 20, 2024

MVCC SEGV_MAPERR when inserting between tuple from select by after=b in not unique index with path (same key in all tuples) and this b #10448

Closed

ivan2kh mentioned this pull request Mar 7, 2025

Segmentation fault when running with sysprof #11233

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix gcc 4.7 warnings with enabled -Wall#8

Fix gcc 4.7 warnings with enabled -Wall#8
kostja merged 1 commit intomasterfrom
gcc-warnings-fix

rtsisyk commented Nov 8, 2012

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

rtsisyk commented Nov 8, 2012

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants