Fixed build on FreeBSD #18
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Other two patches are OK.. |
|
Merged manually. |
zloidemon
added a commit
that referenced
this pull request
Mar 24, 2015
locker
added a commit
that referenced
this pull request
Dec 9, 2017
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
locker
added a commit
that referenced
this pull request
Jan 17, 2018
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
locker
added a commit
that referenced
this pull request
Apr 14, 2019
To propagate changes applied to a space while a new index is being built, we install an on_replace trigger. In case the on_replace trigger callback fails, we abort the DDL operation. The problem is the trigger may yield, e.g. to check the unique constraint of the new index. This opens a time window for the DDL operation to complete and clear the trigger. If this happens, the trigger will try to access the outdated build context and crash: | #0 0x558f29cdfbc7 in print_backtrace+9 | #1 0x558f29bd37db in _ZL12sig_fatal_cbiP9siginfo_tPv+1e7 | #2 0x7fe24e4ab0e0 in __restore_rt+0 | #3 0x558f29bfe036 in error_unref+1a | #4 0x558f29bfe0d1 in diag_clear+27 | #5 0x558f29bfe133 in diag_move+1c | #6 0x558f29c0a4e2 in vy_build_on_replace+236 | #7 0x558f29cf3554 in trigger_run+7a | #8 0x558f29c7b494 in txn_commit_stmt+125 | #9 0x558f29c7e22c in box_process_rw+ec | #10 0x558f29c81743 in box_process1+8b | #11 0x558f29c81d5c in box_upsert+c4 | #12 0x558f29caf110 in lbox_upsert+131 | #13 0x558f29cfed97 in lj_BC_FUNCC+34 | #14 0x558f29d104a4 in lua_pcall+34 | #15 0x558f29cc7b09 in luaT_call+29 | #16 0x558f29cc1de5 in lua_fiber_run_f+74 | #17 0x558f29bd30d8 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e | #18 0x558f29cdca33 in fiber_loop+41 | #19 0x558f29e4e8cd in coro_init+4c To fix this issue, let's recall that when a DDL operation completes, all pending transactions that affect the altered space are aborted by the space_invalidate callback. So to avoid the crash, we just need to bail out early from the on_replace trigger callback if we detect that the current transaction has been aborted. Closes #4152
locker
added a commit
that referenced
this pull request
Apr 16, 2019
To propagate changes applied to a space while a new index is being built, we install an on_replace trigger. In case the on_replace trigger callback fails, we abort the DDL operation. The problem is the trigger may yield, e.g. to check the unique constraint of the new index. This opens a time window for the DDL operation to complete and clear the trigger. If this happens, the trigger will try to access the outdated build context and crash: | #0 0x558f29cdfbc7 in print_backtrace+9 | #1 0x558f29bd37db in _ZL12sig_fatal_cbiP9siginfo_tPv+1e7 | #2 0x7fe24e4ab0e0 in __restore_rt+0 | #3 0x558f29bfe036 in error_unref+1a | #4 0x558f29bfe0d1 in diag_clear+27 | #5 0x558f29bfe133 in diag_move+1c | #6 0x558f29c0a4e2 in vy_build_on_replace+236 | #7 0x558f29cf3554 in trigger_run+7a | #8 0x558f29c7b494 in txn_commit_stmt+125 | #9 0x558f29c7e22c in box_process_rw+ec | #10 0x558f29c81743 in box_process1+8b | #11 0x558f29c81d5c in box_upsert+c4 | #12 0x558f29caf110 in lbox_upsert+131 | #13 0x558f29cfed97 in lj_BC_FUNCC+34 | #14 0x558f29d104a4 in lua_pcall+34 | #15 0x558f29cc7b09 in luaT_call+29 | #16 0x558f29cc1de5 in lua_fiber_run_f+74 | #17 0x558f29bd30d8 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e | #18 0x558f29cdca33 in fiber_loop+41 | #19 0x558f29e4e8cd in coro_init+4c To fix this issue, let's recall that when a DDL operation completes, all pending transactions that affect the altered space are aborted by the space_invalidate callback. So to avoid the crash, we just need to bail out early from the on_replace trigger callback if we detect that the current transaction has been aborted. Closes #4152
locker
added a commit
that referenced
this pull request
Apr 16, 2019
To propagate changes applied to a space while a new index is being built, we install an on_replace trigger. In case the on_replace trigger callback fails, we abort the DDL operation. The problem is the trigger may yield, e.g. to check the unique constraint of the new index. This opens a time window for the DDL operation to complete and clear the trigger. If this happens, the trigger will try to access the outdated build context and crash: | #0 0x558f29cdfbc7 in print_backtrace+9 | #1 0x558f29bd37db in _ZL12sig_fatal_cbiP9siginfo_tPv+1e7 | #2 0x7fe24e4ab0e0 in __restore_rt+0 | #3 0x558f29bfe036 in error_unref+1a | #4 0x558f29bfe0d1 in diag_clear+27 | #5 0x558f29bfe133 in diag_move+1c | #6 0x558f29c0a4e2 in vy_build_on_replace+236 | #7 0x558f29cf3554 in trigger_run+7a | #8 0x558f29c7b494 in txn_commit_stmt+125 | #9 0x558f29c7e22c in box_process_rw+ec | #10 0x558f29c81743 in box_process1+8b | #11 0x558f29c81d5c in box_upsert+c4 | #12 0x558f29caf110 in lbox_upsert+131 | #13 0x558f29cfed97 in lj_BC_FUNCC+34 | #14 0x558f29d104a4 in lua_pcall+34 | #15 0x558f29cc7b09 in luaT_call+29 | #16 0x558f29cc1de5 in lua_fiber_run_f+74 | #17 0x558f29bd30d8 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e | #18 0x558f29cdca33 in fiber_loop+41 | #19 0x558f29e4e8cd in coro_init+4c To fix this issue, let's recall that when a DDL operation completes, all pending transactions that affect the altered space are aborted by the space_invalidate callback. So to avoid the crash, we just need to bail out early from the on_replace trigger callback if we detect that the current transaction has been aborted. Closes #4152 (cherry picked from commit ccd46a2)
locker
added a commit
that referenced
this pull request
Apr 16, 2019
To propagate changes applied to a space while a new index is being built, we install an on_replace trigger. In case the on_replace trigger callback fails, we abort the DDL operation. The problem is the trigger may yield, e.g. to check the unique constraint of the new index. This opens a time window for the DDL operation to complete and clear the trigger. If this happens, the trigger will try to access the outdated build context and crash: | #0 0x558f29cdfbc7 in print_backtrace+9 | #1 0x558f29bd37db in _ZL12sig_fatal_cbiP9siginfo_tPv+1e7 | #2 0x7fe24e4ab0e0 in __restore_rt+0 | #3 0x558f29bfe036 in error_unref+1a | #4 0x558f29bfe0d1 in diag_clear+27 | #5 0x558f29bfe133 in diag_move+1c | #6 0x558f29c0a4e2 in vy_build_on_replace+236 | #7 0x558f29cf3554 in trigger_run+7a | #8 0x558f29c7b494 in txn_commit_stmt+125 | #9 0x558f29c7e22c in box_process_rw+ec | #10 0x558f29c81743 in box_process1+8b | #11 0x558f29c81d5c in box_upsert+c4 | #12 0x558f29caf110 in lbox_upsert+131 | #13 0x558f29cfed97 in lj_BC_FUNCC+34 | #14 0x558f29d104a4 in lua_pcall+34 | #15 0x558f29cc7b09 in luaT_call+29 | #16 0x558f29cc1de5 in lua_fiber_run_f+74 | #17 0x558f29bd30d8 in _ZL16fiber_cxx_invokePFiP13__va_list_tagES0_+1e | #18 0x558f29cdca33 in fiber_loop+41 | #19 0x558f29e4e8cd in coro_init+4c To fix this issue, let's recall that when a DDL operation completes, all pending transactions that affect the altered space are aborted by the space_invalidate callback. So to avoid the crash, we just need to bail out early from the on_replace trigger callback if we detect that the current transaction has been aborted. Closes #4152 (cherry picked from commit ccd46a2)
Closed
drakonhg
pushed a commit
that referenced
this pull request
Sep 2, 2021
locker
added a commit
to locker/tarantool
that referenced
this pull request
Jun 10, 2024
`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
to locker/tarantool
that referenced
this pull request
Jun 11, 2024
`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 pull request
Jun 13, 2024
`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 pull request
Jun 13, 2024
`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 pull request
Jun 13, 2024
`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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Added libintl from gettext.