Corrupt objects running test suite

[c3d]

While running the test suite, the object::object_error function gets invoked.

[c3d]

The stack trace in the debugger shows that this is in the runtime loop running the command (in my case, 12 typename):

    frame #0: 0x0000000100061b70 db48x`object::object_error(object::id, object const*) + 40 at db48x/src/object.cc:714
    frame #1: 0x000000010001b370 db48x`object::type() const + 144 at db48x/src/object.h:249
    frame #2: 0x000000010001b2c4 db48x`object::ops() const + 24 at db48x/src/object.h:261
    frame #3: 0x000000010001aaf8 db48x`object::size() const + 28 at db48x/src/object.h:270
    frame #4: 0x000000010005ec98 db48x`object::skip() const + 28 at db48x/src/object.h:279
  * frame #5: 0x000000010010d640 db48x`runtime::run_next(unsigned long) + 164 at db48x/src/runtime.h:537
    frame #6: 0x000000010010d38c db48x`program::run_loop(unsigned long) + 200 at db48x/src/program.cc:155
    frame #7: 0x000000010010d254 db48x`program::run(bool) const + 384 at db48x/src/program.cc:120
    frame #8: 0x0000000100033d34 db48x`user_interface::end_edit() + 1304 at db48x/src/user_interface.cc:332

The next and end fields are inconsistent (next is after end):

(lldb) p next
(object_p) 0x000000010e8313f4
(lldb) p end
(object_p) 0x000000010e83a2e5

The next field is at rt.Temporaries, which is not normal. This would indicate that the garbage collector did not correctly move it back while compacting, but the record of that happening has been lost. The last gc entries in the recorder are:

[16115398 33.032465] gc: Garbage collection, available 7, range 0x10e831356-0x10e83a39a
[16117658 33.032753] gc: Garbage collection done, purged 36494, available 36501
[16746510 42.259837] gc: Garbage collection, available 251, range 0x10e831356-0x10e83a2e5
[16753701 42.260827] gc: Garbage collection done, purged 36602, available 36853

The range is wrong.

[c3d]

The test next < end passes: next is 0x000000010e8313f4, end is 0x000000010e83a2e5. Since next corresponds to temporaries, this seems to indicate that end was not correctly moved.

[c3d]

Inside object::result program::run(bool synchronous) const, the first and end seem to confirm that theory:

(lldb) p first
p first
(object_p) 0x000000010e83a2e1
(lldb) p end
p end
(object_p) 0x000000010e83a2e5

[c3d]

It's a bit weird and peculiar that this corresponds to the end of the last GC run:

[16746510 42.259837] gc: Garbage collection, available 251, range 0x10e831356-0x10e83a2e5

[c3d]

The good news is that the bug appears to be deterministic. Another run hits the object::object_error exactly at the same spot.

[c3d]

The working theory is that end is pointing past the last object, therefore not moved correctly during garbage collection if it happens to be exactly equal to Temporaries.

[c3d]

Adjusting the end pointer to be inside an object instead of just past it did not solve the problem as expected.