[Vm-dev] debugging the garbage collector

David T. Lewis lewis at mail.msen.com
Fri Feb 15 00:48:04 UTC 2013

On Thu, Feb 14, 2013 at 11:49:49PM +0100, Noah Evans wrote:
> Hey guys,
> I'm working on a port of spoon to Plan 9. I've gotten the system
> accepting events and trying to blit (the primitive fails). However as
> soon as it tries to GC it looks like at some point in the sweep it's
> getting a pointer to object memory rather than a size which leads to a
> page fault.
> Can anyone give me any pointers to documentation or personal
> experience regarding debugging the object memory and GC?
> Best regards,
> Noah

Hello and welcome! Sounds like an interesting project.

I've never brought up a VM on a new platform but I've had some experience
debugging problems like this. The good news is that the failure is probably
happening very shortly after you enter the interpreter loop, which means
if you can run your VM under a debugger and break on entry to interpret(),
you will very likely have the crash occurring not too long afterwards.
The bad news is that the failure will occur at some point that is completely
unrelated to the original source of the problem. I'm not too sophisticated
about this stuff, so I usually end up applying some combination of gdb
breakpoints, printf statements added to the code, and patience.

I'm assuming that your VM is derived from a relatively recent interpreter
VM code base, maybe Craig can confirm? Also, it would be good to know
size of pointer and int data types, I'm totally unfamiliar with Plan 9.
Perhaps you let us know what you get from running this:

  #include <stdio.h>
      printf("size of int %d\nsize of long %d\nsize of long long %d\nsize of void pointer %d\n",
          sizeof(int), sizeof(long), sizeof(long long), sizeof(void *));

For reference, a 32-bit gnu C on Intel (the common case) is:

  size of int 4
  size of long 4
  size of long long 8
  size of void pointer 4

And 64-bit gnu C is:

  size of int 4
  size of long 8
  size of long long 8
  size of void pointer 8


More information about the Vm-dev mailing list