Charles McGarvey wrote:
Nicolas Cannasse wrote:
Charles McGarvey a écrit :
Hey,
I'm trying to track down the reason I'm getting a segfault, but I'm a
little perplexed because my own C code is rather trivial (i.e load a
module, call a neko function in a loop). Here's the backtrace in case
somebody more experienced than myself might be able to glean something
from it. In this case, neko was built with -g and no optimizations and
is running on amd64. At a glance, looks like alloc is returning
null...
Yes, seems like the GC fails to allocate memory when the VM stack
needs to grow. Are you doing some kind of allocation in C ? it's
possible that some C code corrupts GC memory.
You can also enable GC traces in vm/alloc.c by defining GC_LOG and
recompiling NekoVM.
Nicolas
Okay, I upgraded to libgc 7.1 and it's fine now. Thanks.
Just kidding. There's more. The new libgc seems to work fine with one
thread, but the problem reemerged when I enabled more than one thread.
The new libgc is probably just masking the problem and making it appear
in different places. From the new core dump...
--
Program terminated with signal 11, Segmentation fault.
[New process 23291]
[New process 23275]
[New process 23293]
[New process 23292]
#0 0x00007fef2f68c6d8 in neko_vm_dump_stack (vm=0x181fe00) at
vm/interp.c:519
519 printf("%s ",val_string(m->name));
(gdb) bt
#0 0x00007fef2f68c6d8 in neko_vm_dump_stack (vm=0x181fe00) at
vm/interp.c:519
#1 0x00007fef2f686165 in handle_signal (signal=11) at vm/alloc.c:100
#2 <signal handler called>
#3 0x00007fef2eb2bfe0 in memcpy () from /lib/libc.so.6
#4 0x00007fef2f69b068 in neko_stack_expand (sp=0x1812200,
csp=0x1812b80, vm=0x181fe00) at vm/others.c:346
#5 0x00007fef2f68b885 in neko_val_callEx (vthis=0x18129e0, f=0x1718740,
args=0x0, nargs=0, exc=0x0) at vm/callback.c:97
#6 0x0000000000402984 in Web_new (module=0x1711200,
fcgiRequest=0x41e5f080) at Web.c:55
#7 0x0000000000401b49 in ServerLoop (sockfd=<value optimized out>) at
nekoapp.c:202
#8 0x00007fef2f24110f in GC_inner_start_routine () from /usr/lib/libgc.so.1
#9 0x00007fef2f23b495 in GC_call_with_stack_base () from
/usr/lib/libgc.so.1
#10 0x00007fef2ee09037 in start_thread () from /lib/libpthread.so.0
#11 0x00007fef2eb7d03d in clone () from /lib/libc.so.6
#12 0x0000000000000000 in ?? ()
(gdb) frame 4
#4 0x00007fef2f69b068 in neko_stack_expand (sp=0x1812200,
csp=0x1812b80, vm=0x181fe00) at vm/others.c:346
346 memcpy(nsp,vm->spmin,sizeof(int_val) * i);
(gdb) x nsp
0x1878000: 0x00000073
(gdb) x vm->spmin
0x182e8c0: 0x00000073
(gdb) p i
$1 = -14247
(gdb) p sizeof(int_val)
$2 = 8
--
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.
--Chaz
--
Neko : One VM to run them all
(http://nekovm.org)
