Charles McGarvey a écrit :
Nicolas Cannasse wrote:
So it's still that same line, vm/others.c:346. This time, however,
the previous allocation apparently succeeds. It stills fails because
the variable i turns out to be negative when it probably should be
positive. I'm wondering if this has something to do with 32-bit
assumptions somewhere.
Are you on a 64-bit system ? If so, then please have a look at the
neko_stack_expand implementation. int_val should be a 64-bit int.
Please add prints of "size" and "i" and try to understand why "i" is
negative, which of course it shouldn't be...
Well, quite simply the variable i is negative in this case because
vm->spmin is bigger than csp or vm->csp. Unfortunately I haven't a clue
what those variables mean, and I don't know enough about neko internals
to understand why that would be the case.
This of course should not occur.
The VM stack (which pointer is stored into vm->spmin) is divided into
two parts : CSP (call stack pointer) which grows up from SPMIN, and SP
(values stack pointer) which grows down from SPMAX (=SPMIN+StackSize)
So you should always have CSP >= SPMIN-1
The stack values are initialized in vm/interp.c:neko_vm_alloc , then
should only be modified in neko_stack_expand. Please check if something
go wrong in one of these places.
Best,
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
