From: Nikita Pettik <korablev@tarantool.org> To: tarantool-patches@dev.tarantool.org Cc: v.shpilevoy@tarantool.org Subject: [Tarantool-patches] [PATCH v4 0/2] vinyl: fix uninitialized memory accesses Date: Thu, 7 May 2020 04:10:07 +0300 [thread overview] Message-ID: <cover.1588812793.git.korablev@tarantool.org> (raw) Branch: https://github.com/tarantool/tarantool/commits/np/gh-4864-access-to-uninit-mem Issue: https://github.com/tarantool/tarantool/issues/4864 Changes in v2: - replaced error injection ERRINJ_VY_MAX_TUPLE_SIZE with ERRINJ_VY_STMT_ALLOC (i.e. now vy_stmt_alloc() fails not due to exceed max size, but owing to allocation failure); - found another one use-after-free bug in case vy_read_view_merge() fails. Fix is merged into second patch; - added ERRINJ_VY_READ_VIEW_MERGE_FAIL to provide test case in case of vy_read_view_merge() failure; - fixed test covering second bug: error injection value accidentally was set to a wrong value (bad copy-paste). Changes in v3: - instead of nullifing read views (which may lead to tuple leaks), let's call proper finalizing routine vy_read_view_stmt_destroy(); - found another one possible crash due to extra tuple format unref in case of failed compaction; fix to that is introduced in third patch in series. Changes in v4: - removed write history clean up from vy_read_view_stmt_destroy(). Instead write history now is destroyed right in vy_write_iterator_build_read_view() when it is no longer needed; - moved clean-up of all write histories which belong to particular write iterator to one function vy_write_iterator_history_destroy() which unrefs corresponding tuples and releases region memory; - refactored test so that it does not rely on unchecked sleeps; - separated and pushed first patch in series. @ChangeLog: * Fixed crash during compaction due to tuples with size exceeding vinyl_max_tuple_size setting (gh-4864). Nikita Pettik (2): vinyl: clean-up unprocessed read views in *_build_read_views() vinyl: clean-up write iterator if vy_task_write_run() fails src/box/vy_write_iterator.c | 77 +++++-- src/errinj.h | 2 + test/box/errinj.result | 2 + .../gh-4864-stmt-alloc-fail-compact.result | 205 ++++++++++++++++++ .../gh-4864-stmt-alloc-fail-compact.test.lua | 93 ++++++++ 5 files changed, 364 insertions(+), 15 deletions(-) -- 2.17.1
next reply other threads:[~2020-05-07 1:10 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-07 1:10 Nikita Pettik [this message] 2020-05-07 1:10 ` [Tarantool-patches] [PATCH v4 1/2] vinyl: clean-up unprocessed read views in *_build_read_views() Nikita Pettik 2020-05-07 1:10 ` [Tarantool-patches] [PATCH v4 2/2] vinyl: clean-up write iterator if vy_task_write_run() fails Nikita Pettik 2020-05-10 19:49 ` [Tarantool-patches] [PATCH v4 0/2] vinyl: fix uninitialized memory accesses Vladislav Shpilevoy 2020-05-12 14:14 ` Nikita Pettik 2020-05-12 15:59 ` Nikita Pettik
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1588812793.git.korablev@tarantool.org \ --to=korablev@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v4 0/2] vinyl: fix uninitialized memory accesses' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox