[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: bug of GC "step"
- From: "Mauro Iazzi" <mauro.iazzi@...>
- Date: Thu, 3 Jul 2008 00:44:50 +0200
On my computer (x86_64) this runs well. Using -m32 to generate 32 bit
code recreates the freeze.
However it seems to me that this is not a bug. If you read the
definitions of the gc parameters, you will see that you are asking the
collector to start whenever the memory grows over 100% of what's
If a collection cycle has just finished then it cannot reclaim any
memory, and whatever threshold it wants to get under (probably a
percentage of current), it cannot reach it. Thus it remains in the
loop you have seen. Try using collectgarbage("setpause", 101) : it
seems to fix things here.
I have not yet looked into how Lua decides the threshold it should
reach, why and how it is a safe assumption that it will be able to
2008/7/2 Makoto Hamanaka <email@example.com>:
> Thanks for using your time to reproduce the problem.
>> > It is the result. The last call to collectgarbage("step",0) never returns.
>> > I waited 40 minutes and it doesn't respond.
>> >> collectgarbage("setpause",100)
>> >> collectgarbage("setstepmul",2000)
>> >> collectgarbage("stop")
>> >> collectgarbage("step",0)
>> Same results here on Gentoo (5.1.1 compiled from source), and Windows
>> with 5.1.3 from LuaBinaries. However, Windows x64 5.1.3 LuaBinaries
> So, the problem is not alone on my machine ;-)
> I don't have Windows 64bit box to test, but it is interesting.
>> I'm not sure if this is really a bug, as I'm not familiar with the
>> internals of the garbage collection system and it does indeed say the
>> behavior is 'non-specified', but I can say that I don't think Lua should
>> ever enter an infinite loop.
> I agree.
> Makoto Hamanaka <firstname.lastname@example.org>