[Openmcl-devel] Another linux86-32: signed doubleword parameters.

[David Brown]

On Mon, Oct 13, 2008 at 10:59:38AM -0600, Gary Byers wrote:

> mark_root() is called to (of all things ...) mark "root"s, where a
> "root" is a register or stack location (or one of a few other things.)
> It'd be interesting to see who called it; it's usually called from
> mark_[cvt]stack_area() or from mark_xp() (though there may be an
> intervening function or two.)  The various stack marking functions
> obviously traverse a thread's stacks; mark_xp() looks at the registers
> in an exception context.  If we have a lot of threads running and
> those threads are doing lots of I/O (transitioning between running C
> and lisp code), there are lots of things that have to be done exactly
> right.  (We generally say that a GC can occur on any instruction
> boundary; if anyone thinks that that's an exaggeration, they should
> poke around in a crash like this in gdb.)

(gdb) bt
#0  0x0805af25 in mark_root (n=2941) at ../x86-gc.c:292
#1  0x0805c2f4 in mark_xp (xp=0xf6369cf4, node_regs_mask=138) at ../x86-gc.c:1347
#2  0x080595be in mark_tcr_xframes (tcr=0xf636aaa0) at ../gc-common.c:617
#3  0x0805a296 in gc (tcr=0xf5d5caa0, param=0) at ../gc-common.c:1197
#4  0x08061383 in gc_from_tcr (tcr=0xf5d5caa0, param=0) at ../x86-exceptions.c:2621
#5  0x080612c2 in gc_like_from_xp (xp=0xf5d5bcf4, fun=0x806134d <gc_from_tcr>, param=0)
     at ../x86-exceptions.c:2578
#6  0x080613d4 in gc_from_xp (xp=0xf5d5bcf4, param=0) at ../x86-exceptions.c:2633
#7  0x0805e7b4 in handle_gc_trap (xp=0xf5d5bcf4, tcr=0xf5d5caa0) at ../x86-exceptions.c:221
#8  0x0805f9f4 in handle_exception (signum=11, info=0xf5d5bc74, context=0xf5d5bcf4, tcr=0xf5d5caa0, old_valence=0)
     at ../x86-exceptions.c:995
#9  0x0806001b in signal_handler (signum=11, info=0xf5d5bc74, context=0xf5d5bcf4, tcr=0xf5d5caa0, old_valence=0)
     at ../x86-exceptions.c:1242
#10 <signal handler called>
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

The mark_xp looks like it was doing

	if (node_regs_mask & (1<<3)) mark_root(regs[REG_EDX]);

but, with optimization, this might be a little misleading.

regs[REG_EIP] is 0x1400a767, but I'm not quite sure how to figure out
what that is inside of.  What's the easiest way of figuring out what
code that is inside of?

So, does it look like it caught a place where EDX contained a non-lisp
object, but the regs mask indicated it did?

> If this is reapeatable, it's really good news.

Reasonably repeatable.  It happens about one out of 10 times I run the
test.  Other times, it fails with valid incorrect objects getting
caught by something (usually seems to be arrays turning into conses).

David