7-STABLE broke drscheme in week between 4 and 11 Jan

John Baldwin jhb at freebsd.org
Wed Jan 23 07:06:13 PST 2008


On Saturday 19 January 2008 08:29:41 pm Andrew Reilly wrote:
> Hi there,
> 
> I'm still working on debugging this myself, but thought that a
> few more experienced eyes might be able to help me.
> 
> I'm tracking 7-STABLE on my amd64 system, but something
> happened a couple of weeks ago that broke lang/drscheme.
> I've been doing a bit of regressing and testing, and have
> found that a mred executable built against a 7-STABLE
> checkout of 2008.01.04.00.00.00 works fine, but the exact
> same binary crashes with a SEGV on a kernel check-out of
> 2008.01.11.00.00.00.  It's a bit hard to debug, because the
> code in question is a twisty maze of macros, #ifs and inlines,
> because it's in the garbage collector, and that's quite
> platform-sensitive.
> 
> Anyway, the last part of the ktrace of the broken version (the
> earlier parts are just loading up shared libraries) looks like:
> (I sedded the ^pid out, so that I could get a better look at it
> with diff (meld, actually: it's nice)).

There were changes to make binaries get SIGSEGV instead of SIGBUS (or vice
versa) for certain VM-related traps.  That might be related in which case
the source code for the app will need to catch a different signal.  You can
test this by fiddling with the machdep.prot_fault_translation sysctl.
 
> So it looks as though it's in a section just before it
> establishes it's SIGSEGV handler, and so presumably isn't
> expecting to get segv'd just yet.  If it hadn't been segv'd, 
> the next thing to happen was that 
> mredid mred     CALL mmap(0,0x300000,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,0xffffffff,0)
> 
> the faulting instruction is:
> 0x0000000800bdecc6 <GC_init_type_tags+598>:	mov %r13,(%rdx,%rax,8)
> 
> r13 is 0x803900000
> rdx is -1
> rax is 0xe40
> 
> Any thoughts on why that would be faulting?  (Looks like a write
> to a very low address (code?) to me, but I'm not up on the VM
> map yet.)

rdx should be a pointer to an array or some such, but it is a bogus
pointer and that is why you are faulting.

> The only thing that looks appropriate that changed in that week
> was sys/vm/vm_map.c, which had some new code added to help with
> shm mappings.  I looked at it, but it didn't look as though it
> would affect this.

Those changes were only in HEAD, so if you are seeing them in your kernel
you are running HEAD and not RELENG_7.

-- 
John Baldwin


More information about the freebsd-ports mailing list