issue with love.thread

[SiENcE]

I am currently working on Love Threads. Maybe I'm doing something wrong, but I'm getting this here:

Code: Select all

channel 1       true
Error: Thread error (Thread: 0x008996a0)

thread3.lua:8: bad allocation
stack traceback:
        [C]: in function 'push'
        thread3.lua:8: in main chunk
stack traceback:
        [string "boot.lua"]:637: in function <[string "boot.lua"]:633>
        [C]: in function 'error'
        [string "boot.lua"]:521: in function <[string "boot.lua"]:520>
        [string "boot.lua"]:503: in function <[string "boot.lua"]:493>
        [C]: in function 'xpcall'

tested with:
love 0.9.2 (win32 bit) => no support of nested tables (push)
love 0.10.2 (win 32bit) => exception, hard crash
love 0.10.2 (win 64 bit) => no exception, but application stucks from time to time and slows down pc
love 0.11.0 (win 32bit) => exception, the error message above

It only happens when I include thread3. lua. But always for that.

If I add a little "sleep" to the "thread3.lua", it gets an "exception". I suspect that the push implementation is causing the problem.

Help appreciated

[pgimeno]

Code: Select all

local maze = {
    {1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2, 1, 2},
    ...
}

...

        success = channel:supply( maze )

The documentation doesn't mention nested tables to be supported. I wonder if that's a documentation problem or a 0.10 problem. If it's a documentation problem, I'd have to look further. But I suspect it's a bug in 0.10 to not give an error when passed a table that is not flat.

[grump]

It's a bug. Pushing nested tables works fine in 0.10.2. I'm using this extensively in a project, up to 3 levels deep.

[raidho36]

Could the problem be that you're trying to push an absolute shit ton of data to the channel at a time? The thread3 tries to push 30 billion values, which is something like half a terabyte of memory, if you're modest.

Because you're pushing the values as fast as the CPU could do it but you only pop them like 60 times per second.

Also apparently removing data from channel doesn't free up the memory. That's becasue std::queue doesn't automatically shrinks if you remove elements. I guess it should be noted in wiki that if you keep a lot of data active in the channel, the memory consumption will not decrease after you clear it, you must destroy it altogether if you want that memory back.

[SiENcE]

The documentation doesn't mention nested tables to be supported. I wonder if that's a documentation problem or a 0.10 problem. If it's a documentation problem, I'd have to look further. But I suspect it's a bug in 0.10 to not give an error when passed a table that is not flat.

The nested table is no problem. Here attached is one without and it gives the same result (crash).

Could the problem be that you're trying to push an absolute shit ton of data to the channel at a time? The thread3 tries to push 30 billion values, which is something like half a terabyte of memory, if you're modest.

Because you're pushing the values as fast as the CPU could do it but you only pop them like 60 times per second.

Also apparently removing data from channel doesn't free up the memory. That's becasue std::queue doesn't automatically shrinks if you remove elements. I guess it should be noted in wiki that if you keep a lot of data active in the channel, the memory consumption will not decrease after you clear it, you must destroy it altogether if you want that memory back.

I would agree to you, but it's only one number pushed at a time. Also why it does get unstable, when performance rises!? (So when i exchange thread3 for thread2) ... or add a sleep to thread3 to eleminate this problem.

So regardless what i do, love2d shouldn't crash :-). It's a bit heavy, but call it load test.

Also it's reproduceable with my example. So it's clearly a bug.

[raidho36]

it's only one number pushed at a time

You're pushing the next number as soon as the previous push operation ended, which is pretty fast, I guess something like 100 million per second. You pop them at a rate of 60 numbers per second. Naturally these numbers will accumulate at an extremely rapid pace, and because you set the limit at 30 billion, it would entirely exhaust all available memory and eventually crash. It is a bug, but not with LÖVE code, it's with your own.

[pgimeno]

For me it crashes after exceeding the memory limit in 32 bits, and it doesn't crash in 64 bits but it fills up my RAM and starts swapping, at which point I've stopped it to ensure it doesn't affect other applications.

I get this error in 32 bits when that happens:

Code: Select all

Error: main.lua:107: std::bad_alloc
stack traceback:
        [C]: in function 'print'
        main.lua:107: in function 'draw'
        [string "boot.lua"]:468: in function <[string "boot.lua"]:436>
        [C]: in function 'xpcall'

The line is 105 instead for the nested tables example.

In view of that, I think raidho's diagnosis is right.

[SiENcE]

But line 107 makes no sense at all nor 105.

When you both speak about "memory" limit...what do you mean?

The process explorer tells me this when it crashes and this doesn't look like my memory is exploding :

[raidho36]

Why doesn't it makes sense? You create text so some memory has to be allocated. If it can't be allocated, the game will crash.

[pgimeno]

Forgot to say, I've tested in Linux.

In Windows, the limit for a 32 bit process is 2 Gb. https://msdn.microsoft.com/en-us/librar ... 85%29.aspx

Does it hit the limit at 1.2 Gb? It should not crash until it gets to 2 Gb.

In the 64 bit machine, I'd bet it starts swapping to disk when it fills the memory, and that's why it pauses occasionally and slows down the rest.