Re: PATCH: fixes bug with calling garbage collector from custom lua_Alloc

["Bogdan Marinescu" <bogdan.marinescu@...>]

I can't test right now, but it might be here:

static void script_run_gc(script_info_t *info, size_t need)
{
...............................
#else
	size_t step_size = ((need >> 10) + 1) * GC_STEP_SIZE_MUL;
	size_t old_memused = info->memused;
	int cycle_count = 0;
	do {
		if(lua_gc(info->L, LUA_GCSTEP, step_size)) {
			/* only allow completing the last cycle and starting a new cycle. */
			if((++cycle_count) > 1) break;
		}
	} while((info->memused + need) >= info->max_memused);
	//printf("freed=%zd, need=%d\n", (old_memused - info->memused),need);
#endif
}

"if(lua_gc(info->L, LUA_GCSTEP, step_size))" <- if lua_gc returns
false, it's possible that the do...while block runs forever. Did you
try with step collection or full collection?

On Fri, May 9, 2008 at 12:09 PM, Robert G. Jakabosky
<bobby@sharedrealm.com> wrote:
> On Friday 09, Bogdan Marinescu wrote:
>> To Robert: I tried to run "factorial.lua" and "bisect.lua" with a
>> memory limit of 20000 bytes (using the default system allocator this
>> time (malloc from Linux), so this is not an allocator issue) and it
>> seems that Lua enters an infinite loop somehow. I didn't have the time
>> to investigate this.
> I tried those scripts with my lua_memlimit program and can't reproduce that
> bug.  I just get "not enough memory" errors.  Does the infinite loop only
> happen with the step collection modes?  If the allocator is
> calling "lua_gc(L, LUA_STEP, step_size);" multiple times until there is
> enough free memory to do the allocation, then make sure it stops after two
> completed collection cycles have been reported.  If that is not the problem
> can you try to capture a stack trace of the infinite loop?
>
> --
> Robert G. Jakabosky
>