Date: Wed, 23 Jan 2008 09:04:58 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-stable@freebsd.org Cc: Andrew Reilly <andrew-freebsd@areilly.bpc-users.org>, freebsd-ports@freebsd.org Subject: Re: 7-STABLE broke drscheme in week between 4 and 11 Jan Message-ID: <200801230904.58711.jhb@freebsd.org> In-Reply-To: <20080120012941.GA8588@duncan.reilly.home> References: <20080120012941.GA8588@duncan.reilly.home>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801230904.58711.jhb>