Re: bug of GC "step"

["Mauro Iazzi" <mauro.iazzi@...>]

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
currently used.

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
reach it.

2008/7/2 Makoto Hamanaka <naraxx800@yahoo.co.jp>:
> 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
>> completes.
>
> 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.
>
>
> Thanks,
> Makoto Hamanaka <naraxx800@yahoo.co.jp>
>
>