From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 557DF6E233; Wed, 11 Nov 2026 19:34:06 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 557DF6E233 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1794414846; bh=2NU9tmuPG/wmLvr5XBWO3lnrAVqXF5iM0jc4FKsO13w=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=iOsDsLFjRYXnrJUF0pDtE2/Vj3w6qRin5kekaqLZr50g2ZHiXBYcpqzP768Ut7L7p NJchegV5qn8dmVAe54lzg2JvLlNZQ2IOyIHf0lyFPhQ5dofC8UU0KyIJomQJWnmoya zYVbmnWJNMbjuTHcoCBBdoQhv3IXHziktoZu7ZeA= Received: from send35.i.mail.ru (send35.i.mail.ru [89.221.237.130]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 792686E233 for ; Wed, 11 Nov 2026 19:34:03 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 792686E233 Received: by exim-smtp-bccb94844-zrhvh with esmtpa (envelope-from ) id 1xRBGs-00000000XTu-1OCp; Wed, 11 Nov 2026 19:34:02 +0300 Message-ID: Date: Wed, 11 Nov 2026 19:34:02 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Sergey Bronnikov References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailru-Src: smtp X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9CC39C64ECE24C2D7E46AFCFF31E72140D7017F1BC49F495F182A05F538085040FCD5EBE48DA275A23DE06ABAFEAF670529F2DC00C46080FF193FE39C02FC4EABF8A48EF99929F69E X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE78E8764B5BC580342EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637AC83A81C8FD4AD23D82A6BABE6F325AC2E85FA5F3EDFCBAA7353EFBB553375661F398E59D6539FAAF7B0FA6380D6D30712F01CA483E64193F0550B88440C2D9E389733CBF5DBD5E9D5E8D9A59859A8B625DC386152A6764ACC7F00164DA146DA6F5DAA56C3B73B237318B6A418E8EAB8090A508E0FED6299176DF2183F8FC7C04DC5992C2AE98860CD04E86FAF290E2DB606B96278B59C421DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6936FEDF0B958011F089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5BFE98EEE52ED83B45002B1117B3ED696EDC73B3F9AA94E898D59E407A97E9958823CB91A9FED034534781492E4B8EEAD831CA35E4C50C31B X-C8649E89: 1C3962B70DF3F0AD73CAD6646DEDE191716CD42B3DD1D34CAB70F9BE574AE9C625B6776AC983F447FC0B9F89525902EE6F57B2FD27647F25E66C117BDB76D65904E5052C4BADCEC81CDA6F18FF78483D0C1885313773C03C59254BDEC41461455B1E4FE85C8DF4ACB8341EE9D5BE9A0AA30E0022888D6905E69CDF93D3AC4DCC6729332814387AF29350E1BD188BD56E4C41F94D744909CEEF9E35A692215F79327F81E6EEE0AEB67A0F9F91F029B6AF33F2C28C22F508233FCF178C6DD14203 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu53w8ahmwBjZKM/YPHZyZHvz5uv+WouB9+ObcCpyrx6l7KImUglyhkEat/+ysWwi0gdhEs0JGjl6ggRWTy1haxBpVdbIX1nthFXOcIETfglQORZ0zpDET4Zrk3igikrdHlWN7HhbiNaJXdDLEd9SnCO68= X-Mailru-Sender: 015BA6FC0EFA223A63A6570A1A03128578D28E1F4A5FA1EDB951B70A5BD4BD8EE43C104F4EAC398F7CA6E38403FCF3F5E62B12C1FE0372A178274A4A9E9E44FD2A114EDA040D8818F01FF9DF31C397A372D6B4FCE48DF648AE208404248635DF X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH luajit 2/3] sysprof: fix crash on a failed stream flush X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Evgeniy Temirgaleev via Tarantool-patches Reply-To: Evgeniy Temirgaleev Cc: tarantool-patches@dev.tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Sergey! At the end of the letter for commit 1/3 I write a note on lj_wbuf_addn() implementation. Actually, this note and question is closer to this commit. Please, see. On 11/2/26 4:12 PM, Sergey Bronnikov wrote: > From: Sergey Bronnikov > > A writer may release the stream buffer and set its pointer to NULL > on an unrecoverable error, e.g., when the file system with the > profile is full. The write buffer stops the stream in this case, > but a caller of `wbuf_reserve()` still writes data using the > released buffer. This leads to a null pointer dereference inside > `lj_utils_write_uleb128()` when the flush is triggered while > streaming a sample. > > Now `wbuf_reserve()` reports whether the stream was stopped during > the flush. All the write functions skip writing in this case, > including the loop pumping a large payload through the buffer. > > Fixes tarantool/tarantool#11620 > --- > src/lj_wbuf.c | 20 +- > .../gh-11620-sysprof-enospc-crash.test.c | 180 ++++++++++++++++++ > test/tarantool-c-tests/unit-wbuf.test.c | 102 ++++++++++ > 3 files changed, 298 insertions(+), 4 deletions(-) > create mode 100644 test/tarantool-c-tests/gh-11620-sysprof-enospc-crash.test.c > > diff --git a/src/lj_wbuf.c b/src/lj_wbuf.c > index 0001a02e..0794b186 100644 > --- a/src/lj_wbuf.c > +++ b/src/lj_wbuf.c > @@ -51,11 +51,18 @@ void LJ_FASTCALL lj_wbuf_terminate(struct lj_wbuf *buf) > lj_wbuf_init(buf, NULL, NULL, NULL, 0); > } > > -static LJ_AINLINE void wbuf_reserve(struct lj_wbuf *buf, size_t n) > +/* > +** Reserve n bytes in the buffer. Returns non-zero if the space is reserved > +** and zero if the stream was stopped during the flush. In the latter case > +** the writer may release the buffer (buf->buf == NULL), so it must not be > +** used by the caller. > +*/ > +static LJ_AINLINE int wbuf_reserve(struct lj_wbuf *buf, size_t n) > { > lj_assertX(n <= buf->size, "wbuf overflow"); > if (LJ_UNLIKELY(wbuf_left(buf) < n)) > lj_wbuf_flush(buf); > + return !lj_wbuf_test_flag(buf, STREAM_STOP); > } > > /* Writes a byte to the output buffer. */ > @@ -63,7 +70,8 @@ void LJ_FASTCALL lj_wbuf_addbyte(struct lj_wbuf *buf, uint8_t b) > { > if (LJ_UNLIKELY(lj_wbuf_test_flag(buf, STREAM_STOP))) > return; > - wbuf_reserve(buf, sizeof(b)); > + if (LJ_UNLIKELY(!wbuf_reserve(buf, sizeof(b)))) > + return; > *buf->pos++ = b; > } > > @@ -72,7 +80,8 @@ void LJ_FASTCALL lj_wbuf_addu64(struct lj_wbuf *buf, uint64_t n) > { > if (LJ_UNLIKELY(lj_wbuf_test_flag(buf, STREAM_STOP))) > return; > - wbuf_reserve(buf, LEB128_U64_MAXSIZE); > + if (LJ_UNLIKELY(!wbuf_reserve(buf, LEB128_U64_MAXSIZE))) > + return; Is it OK, if the writer report an error only, the buffer content will be discarded (not written), and we will success in 'pushing more data to the stream buffer after a hole'? > buf->pos += (ptrdiff_t)lj_utils_write_uleb128(buf->pos, n); > } > > @@ -91,11 +100,14 @@ void lj_wbuf_addn(struct lj_wbuf *buf, const void *src, size_t n) > memcpy(buf->pos, src, left); > buf->pos += (ptrdiff_t)left; > lj_wbuf_flush(buf); > + if (LJ_UNLIKELY(lj_wbuf_test_flag(buf, STREAM_STOP))) > + return; What would happen if writer() reports an error, but doesn't stop a stream? > src = (uint8_t *)src + (ptrdiff_t)left; > n -= left; > } > > - wbuf_reserve(buf, n); > + if (LJ_UNLIKELY(!wbuf_reserve(buf, n))) > + return; > memcpy(buf->pos, src, n); > buf->pos += (ptrdiff_t)n; > } > diff --git a/test/tarantool-c-tests/gh-11620-sysprof-enospc-crash.test.c b/test/tarantool-c-tests/gh-11620-sysprof-enospc-crash.test.c > new file mode 100644 > index 00000000..0f5ffe53 > --- /dev/null > +++ b/test/tarantool-c-tests/gh-11620-sysprof-enospc-crash.test.c -- -- Best regards, Evgeniy Temirgaleev