From owner-freebsd-stable@FreeBSD.ORG Wed Jan 23 14:49:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73BC316A469 for ; Wed, 23 Jan 2008 14:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 582F213C4E3 for ; Wed, 23 Jan 2008 14:49:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from zion.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by elvis.mu.org (Postfix) with ESMTP id 330E51A4D80; Wed, 23 Jan 2008 06:45:50 -0800 (PST) From: John Baldwin To: freebsd-stable@freebsd.org Date: Wed, 23 Jan 2008 09:04:58 -0500 User-Agent: KMail/1.9.7 References: <20080120012941.GA8588@duncan.reilly.home> In-Reply-To: <20080120012941.GA8588@duncan.reilly.home> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801230904.58711.jhb@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: Re: 7-STABLE broke drscheme in week between 4 and 11 Jan X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2008 14:49:42 -0000 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 : 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