Tarantool development patches archive
 help / color / mirror / Atom feed
* [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
@ 2023-11-09 13:45 Maksim Kokryashkin via Tarantool-patches
  2023-11-13  6:58 ` Sergey Kaplun via Tarantool-patches
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Maksim Kokryashkin via Tarantool-patches @ 2023-11-09 13:45 UTC (permalink / raw)
  To: tarantool-patches, sergeyb, skaplun, m.kokryashkin; +Cc: Maksim Kokryashkin

This test could do allocation outside of the protected frame,
which could result in an uncaught OOM and test failure. This
patch adds extra `collectgarbage` calls to the test to avoid
such situations.
---
Changes in v2:
- Fixed comments as per review by Sergey Kaplun
Branch: https://github.com/tarantool/luajit/tree/fckxorg/lj-1004-fix-flaky
PR: https://github.com/tarantool/tarantool/pull/9318
 test/tarantool-tests/lj-1004-oom-error-frame.test.lua | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
index 3be6b555..2ddb5765 100644
--- a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
+++ b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
@@ -10,6 +10,8 @@ test:plan(2)

 local testoomframe = require('testoomframe')

+collectgarbage()
+
 local anchor_memory = {} -- luacheck: no unused
 local function eatchunks(size)
   while true do
@@ -34,6 +36,11 @@ local function chomp()
 end

 local st, err = pcall(chomp)
+
+-- Prevent OOM outside of the protected frame.
+anchor_memory = nil
+collectgarbage()
+
 test:ok(st == false, 'on-trace error handled successfully')
 test:like(err, 'not enough memory', 'error is OOM')
 test:done(true)
--
2.39.3 (Apple Git-145)


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-09 13:45 [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test Maksim Kokryashkin via Tarantool-patches
@ 2023-11-13  6:58 ` Sergey Kaplun via Tarantool-patches
  2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
  2023-11-23  6:32 ` Igor Munkin via Tarantool-patches
  2 siblings, 0 replies; 9+ messages in thread
From: Sergey Kaplun via Tarantool-patches @ 2023-11-13  6:58 UTC (permalink / raw)
  To: Maksim Kokryashkin; +Cc: tarantool-patches

Hi, Maxim!
Thanks for the fixes!
LGTM!

-- 
Best regards,
Sergey Kaplun

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-09 13:45 [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test Maksim Kokryashkin via Tarantool-patches
  2023-11-13  6:58 ` Sergey Kaplun via Tarantool-patches
@ 2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
  2023-11-18 17:55   ` Sergey Bronnikov via Tarantool-patches
                     ` (2 more replies)
  2023-11-23  6:32 ` Igor Munkin via Tarantool-patches
  2 siblings, 3 replies; 9+ messages in thread
From: Sergey Bronnikov via Tarantool-patches @ 2023-11-18 16:52 UTC (permalink / raw)
  To: Maksim Kokryashkin, tarantool-patches, skaplun, m.kokryashkin

Hello, Max

LGTM with a question below


On 11/9/23 16:45, Maksim Kokryashkin wrote:
> This test could do allocation outside of the protected frame,
> which could result in an uncaught OOM and test failure. This
> patch adds extra `collectgarbage` calls to the test to avoid
> such situations.
> ---
> Changes in v2:
> - Fixed comments as per review by Sergey Kaplun
> Branch: https://github.com/tarantool/luajit/tree/fckxorg/lj-1004-fix-flaky
> PR: https://github.com/tarantool/tarantool/pull/9318
>   test/tarantool-tests/lj-1004-oom-error-frame.test.lua | 7 +++++++
>   1 file changed, 7 insertions(+)
>
> diff --git a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
> index 3be6b555..2ddb5765 100644
> --- a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
> +++ b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
> @@ -10,6 +10,8 @@ test:plan(2)
>
>   local testoomframe = require('testoomframe')
>
> +collectgarbage()

Probably it is obvious, but I don't get it.

Usually for forcing garbage collecting one need call `collectgarbage()` 
two times:

for mark and sweep. You call it single time, why?


> +
>   local anchor_memory = {} -- luacheck: no unused
>   local function eatchunks(size)
>     while true do
> @@ -34,6 +36,11 @@ local function chomp()
>   end
>
>   local st, err = pcall(chomp)
> +
> +-- Prevent OOM outside of the protected frame.
> +anchor_memory = nil
> +collectgarbage()
Ditto.
> +
>   test:ok(st == false, 'on-trace error handled successfully')
>   test:like(err, 'not enough memory', 'error is OOM')
>   test:done(true)
> --
> 2.39.3 (Apple Git-145)
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
@ 2023-11-18 17:55   ` Sergey Bronnikov via Tarantool-patches
  2023-11-19 11:49   ` Maxim Kokryashkin via Tarantool-patches
  2023-11-20 14:53   ` Igor Munkin via Tarantool-patches
  2 siblings, 0 replies; 9+ messages in thread
From: Sergey Bronnikov via Tarantool-patches @ 2023-11-18 17:55 UTC (permalink / raw)
  To: Maksim Kokryashkin, tarantool-patches, skaplun, m.kokryashkin

Just for the record:

Fixed test executed 500 times without fails, test with reverted fix had 
failed on 138 iteration with:

/home/sergeyb/sources/MRG/tarantool/third_party/luajit/test/tarantool-tests/lj-1004-oom-error-frame.test.lua 
(Wstat: 256 Tests: 0 Failed: 0)
   Non-zero exit status: 1
   Parse errors: Bad plan.  You planned 2 tests but ran 0.
Files=101, Tests=480,  4 wallclock secs ( 0.25 usr  0.11 sys + 8.70 
cusr  4.55 csys = 13.61 CPU)
Result: FAIL

On 11/18/23 19:52, Sergey Bronnikov via Tarantool-patches wrote:

<snipped>


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches]  [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
  2023-11-18 17:55   ` Sergey Bronnikov via Tarantool-patches
@ 2023-11-19 11:49   ` Maxim Kokryashkin via Tarantool-patches
  2023-11-20 14:53   ` Igor Munkin via Tarantool-patches
  2 siblings, 0 replies; 9+ messages in thread
From: Maxim Kokryashkin via Tarantool-patches @ 2023-11-19 11:49 UTC (permalink / raw)
  To: Sergey Bronnikov; +Cc: Maksim Kokryashkin, tarantool-patches

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]


Hi!
Thanks for the review!
Here is the answer from the «Programming in Lua» (3rd edition), paragraph 32.2:
> From Lua we use the collectgarbage function: collectgarbage(what [, data])
> Both offer the same functionality. The what argument (an enumeration value in C, a string in Lua) specifies what to do. The > options are:
<snipped>
> LUA_GCCOLLECT (“collect”): performs a complete garbage-collection cycle, so that all unreachable objects are collected and finalized. This is the default option for collectgarbage.
 
--
Best regards,
Maxim Kokryashkin
 
  
>Суббота, 18 ноября 2023, 19:52 +03:00 от Sergey Bronnikov <sergeyb@tarantool.org>:
> 
>Hello, Max
>
>LGTM with a question below
>
>
>On 11/9/23 16:45, Maksim Kokryashkin wrote:
>> This test could do allocation outside of the protected frame,
>> which could result in an uncaught OOM and test failure. This
>> patch adds extra `collectgarbage` calls to the test to avoid
>> such situations.
>> ---
>> Changes in v2:
>> - Fixed comments as per review by Sergey Kaplun
>> Branch:  https://github.com/tarantool/luajit/tree/fckxorg/lj-1004-fix-flaky
>> PR:  https://github.com/tarantool/tarantool/pull/9318
>> test/tarantool-tests/lj-1004-oom-error-frame.test.lua | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
>> index 3be6b555..2ddb5765 100644
>> --- a/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
>> +++ b/test/tarantool-tests/lj-1004-oom-error-frame.test.lua
>> @@ -10,6 +10,8 @@ test:plan(2)
>>
>> local testoomframe = require('testoomframe')
>>
>> +collectgarbage()
>
>Probably it is obvious, but I don't get it.
>
>Usually for forcing garbage collecting one need call `collectgarbage()`
>two times:
>
>for mark and sweep. You call it single time, why?
>
>
>> +
>> local anchor_memory = {} -- luacheck: no unused
>> local function eatchunks(size)
>> while true do
>> @@ -34,6 +36,11 @@ local function chomp()
>> end
>>
>> local st, err = pcall(chomp)
>> +
>> +-- Prevent OOM outside of the protected frame.
>> +anchor_memory = nil
>> +collectgarbage()
>Ditto.
>> +
>> test:ok(st == false, 'on-trace error handled successfully')
>> test:like(err, 'not enough memory', 'error is OOM')
>> test:done(true)
>> --
>> 2.39.3 (Apple Git-145)
>>
 

[-- Attachment #2: Type: text/html, Size: 3300 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
  2023-11-18 17:55   ` Sergey Bronnikov via Tarantool-patches
  2023-11-19 11:49   ` Maxim Kokryashkin via Tarantool-patches
@ 2023-11-20 14:53   ` Igor Munkin via Tarantool-patches
  2023-11-22 15:28     ` Sergey Bronnikov via Tarantool-patches
  2023-11-22 15:30     ` Sergey Bronnikov via Tarantool-patches
  2 siblings, 2 replies; 9+ messages in thread
From: Igor Munkin via Tarantool-patches @ 2023-11-20 14:53 UTC (permalink / raw)
  To: Sergey Bronnikov; +Cc: Maksim Kokryashkin, tarantool-patches

Sergey,

On 18.11.23, Sergey Bronnikov via Tarantool-patches wrote:
> Hello, Max
> 
> LGTM with a question below
> 
> 
> On 11/9/23 16:45, Maksim Kokryashkin wrote:

<snipped>

> > 
> > +collectgarbage()
> 
> Probably it is obvious, but I don't get it.
> 
> Usually for forcing garbage collecting one need call `collectgarbage()` two
> times:
> 
> for mark and sweep. You call it single time, why?

The reason of two consequent <collectgarbage> calls is not for "mark and
sweep" but rather for "full GC cycle + finalization of the resurrected
objects". The first call implements full (even 1.5) GC cycle; as a
result of this call some *objects* can be *released*, but the
corresponding *memory* is preserved in another list (gc->mmudata, IIRC)
to properly finalize the object (i.e. call __gc metamethod). Hence, the
second call finally releases the memory for the objects resurrected
within the sweep phase of the first call.

Since Max allocates plain FFI objects with no <ffi.gc> finalizers,
there is no need in the second <collectgarbage> call here.

> 

<snipped>

> > 

-- 
Best regards,
IM

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-20 14:53   ` Igor Munkin via Tarantool-patches
@ 2023-11-22 15:28     ` Sergey Bronnikov via Tarantool-patches
  2023-11-22 15:30     ` Sergey Bronnikov via Tarantool-patches
  1 sibling, 0 replies; 9+ messages in thread
From: Sergey Bronnikov via Tarantool-patches @ 2023-11-22 15:28 UTC (permalink / raw)
  To: Igor Munkin; +Cc: Maksim Kokryashkin, tarantool-patches

Igor,


thanks for explanation!

On 11/20/23 17:53, Igor Munkin wrote:
> Sergey,
>
> On 18.11.23, Sergey Bronnikov via Tarantool-patches wrote:
>> Hello, Max
>>
>> LGTM with a question below
>>
>>
>> On 11/9/23 16:45, Maksim Kokryashkin wrote:
> <snipped>
>
>>> +collectgarbage()
>> Probably it is obvious, but I don't get it.
>>
>> Usually for forcing garbage collecting one need call `collectgarbage()` two
>> times:
>>
>> for mark and sweep. You call it single time, why?
> The reason of two consequent <collectgarbage> calls is not for "mark and
> sweep" but rather for "full GC cycle + finalization of the resurrected
> objects". The first call implements full (even 1.5) GC cycle; as a
> result of this call some *objects* can be *released*, but the
> corresponding *memory* is preserved in another list (gc->mmudata, IIRC)
> to properly finalize the object (i.e. call __gc metamethod). Hence, the
> second call finally releases the memory for the objects resurrected
> within the sweep phase of the first call.
>
> Since Max allocates plain FFI objects with no <ffi.gc> finalizers,
> there is no need in the second <collectgarbage> call here.
>
> <snipped>
>

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-20 14:53   ` Igor Munkin via Tarantool-patches
  2023-11-22 15:28     ` Sergey Bronnikov via Tarantool-patches
@ 2023-11-22 15:30     ` Sergey Bronnikov via Tarantool-patches
  1 sibling, 0 replies; 9+ messages in thread
From: Sergey Bronnikov via Tarantool-patches @ 2023-11-22 15:30 UTC (permalink / raw)
  To: Maksim Kokryashkin, m.kokryashkin; +Cc: tarantool-patches

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

Max,

I would put this text to a comment for clarity.

Feel free to ignore.

On 11/20/23 17:53, Igor Munkin wrote:

<snipped>
> The reason of two consequent <collectgarbage> calls is not for "mark and
> sweep" but rather for "full GC cycle + finalization of the resurrected
> objects". The first call implements full (even 1.5) GC cycle; as a
> result of this call some *objects* can be *released*, but the
> corresponding *memory* is preserved in another list (gc->mmudata, IIRC)
> to properly finalize the object (i.e. call __gc metamethod). Hence, the
> second call finally releases the memory for the objects resurrected
> within the sweep phase of the first call.
>
> Since Max allocates plain FFI objects with no <ffi.gc> finalizers,
> there is no need in the second <collectgarbage> call here.
>
<snipped>

[-- Attachment #2: Type: text/html, Size: 1334 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test
  2023-11-09 13:45 [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test Maksim Kokryashkin via Tarantool-patches
  2023-11-13  6:58 ` Sergey Kaplun via Tarantool-patches
  2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
@ 2023-11-23  6:32 ` Igor Munkin via Tarantool-patches
  2 siblings, 0 replies; 9+ messages in thread
From: Igor Munkin via Tarantool-patches @ 2023-11-23  6:32 UTC (permalink / raw)
  To: Maksim Kokryashkin; +Cc: tarantool-patches

Max,

I've checked this patch into tarantool/master branch in tarantool/luajit
and bumped a new version in master.

On 09.11.23, Maksim Kokryashkin via Tarantool-patches wrote:
> This test could do allocation outside of the protected frame,
> which could result in an uncaught OOM and test failure. This
> patch adds extra `collectgarbage` calls to the test to avoid
> such situations.
> ---
> Changes in v2:
> - Fixed comments as per review by Sergey Kaplun
> Branch: https://github.com/tarantool/luajit/tree/fckxorg/lj-1004-fix-flaky
> PR: https://github.com/tarantool/tarantool/pull/9318
>  test/tarantool-tests/lj-1004-oom-error-frame.test.lua | 7 +++++++
>  1 file changed, 7 insertions(+)
> 

<snipped>

> --
> 2.39.3 (Apple Git-145)
> 

-- 
Best regards,
IM

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2023-11-23  6:40 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-09 13:45 [Tarantool-patches] [PATCH luajit v2] test: fix flaky OOM error frame test Maksim Kokryashkin via Tarantool-patches
2023-11-13  6:58 ` Sergey Kaplun via Tarantool-patches
2023-11-18 16:52 ` Sergey Bronnikov via Tarantool-patches
2023-11-18 17:55   ` Sergey Bronnikov via Tarantool-patches
2023-11-19 11:49   ` Maxim Kokryashkin via Tarantool-patches
2023-11-20 14:53   ` Igor Munkin via Tarantool-patches
2023-11-22 15:28     ` Sergey Bronnikov via Tarantool-patches
2023-11-22 15:30     ` Sergey Bronnikov via Tarantool-patches
2023-11-23  6:32 ` Igor Munkin via Tarantool-patches

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox