[Tarantool-patches] [PATCH 1/2] vinyl: init all vars before cleanup in vy_lsm_split_range()

[Nikita Pettik]

On 13 Apr 22:29, Nikita Pettik wrote:
> On 11 Apr 19:39, Vladislav Shpilevoy wrote:
> > >>> diff --git a/src/box/vy_lsm.c b/src/box/vy_lsm.c
> > >>> index 3d3f41b7a..04c9926a8 100644
> > >>> --- a/src/box/vy_lsm.c
> > >>> +++ b/src/box/vy_lsm.c
> > >>> @@ -134,6 +134,11 @@ vy_stmt_alloc(struct tuple_format *format, uint32_t bsize)
> > >>>  {
> > >>>  	uint32_t total_size = sizeof(struct vy_stmt) + format->field_map_size +
> > >>>  		bsize;
> > >>> +	struct errinj *inj = errinj(ERRINJ_VY_MAX_TUPLE_SIZE, ERRINJ_INT);
> > >>> +	if (inj != NULL && inj->iparam >= 0) {
> > >>> +		if (inj->iparam-- == 0)
> > >>
> > >> 1. You set ERRINJ_VY_MAX_TUPLE_SIZE to an integer. Why not to a boolean,
> > >> which would set it to false instead of decrement? That would make it
> > >> clear the injection works only once.
> > > 
> > > Cause integer allows setting delay of vy_stmt_alloc() failure.
> > > For instance, I don't want first invocation to vy_stmt_alloc()
> > > fail, but the second, third or tenth one - it may turn out to be
> > > vital. This patch fixes bug when first call of vy_stmt_alloc()
> > > during compaction fails; the next patch - if tenth call of
> > > vy_stmt_alloc() fails.
> > 
> > Nope, in the next patch you use 0 too. Moreover, when I changed it
> > to 10, I got the test hanging in 100% CPU. Regardless of with the
> > fix or without.
> 
> It should have been 10. Kind of strange since it is exactly this
> value that helped me to reveal this bug. Mb it is still unpredictable
> consequences of invalid memory access. I will investigate and test on
> my mac before next updates. Thx.
>  
> > >> Also it looks too artificial. The injection basically simulates a tuple
> > >> with too big size which was inserted bypassing max_tuple_size check,
> > >> and suddenly it was checked here, already after insertion.

I've tested on my mac: without fix Tarantool really gets stuck.
But when I run process in gdb/lldb it always crashes (in the same
place as on my linux machine - when accessing invalid memory). So
I assume accessing invalid memory may result in any behaviour
whether it is infinite loop or crash. With applied fix everything
works OK on both linux and mac.
 
> > > Konstantint said, that squashing two upserts of size 'x' may result
> > > in new vy_stmt with size > 'x'. Despite the fact that I did not
> > > attempt at reproducing this statement, I saw these errors appearing
> > > on production machine during compaction. I do not know the exact reason
> > > why they revealed, but it is a fact.
> > 
> > And still this particular test does not use any upserts. So OOM here
> > is more likely to happen than max tuple size violation.
> > 
> > >> Better add an OOM injection for malloc a few lines below, would be more
> > >> correct.