7-STABLE broke drscheme in week between 4 and 11 Jan
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
> 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.
More information about the freebsd-ports