From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17567 invoked by alias); 26 Jan 2006 23:42:05 -0000 Received: (qmail 17559 invoked by uid 22791); 26 Jan 2006 23:42:05 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.206) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 26 Jan 2006 23:42:04 +0000 Received: by zproxy.gmail.com with SMTP id x3so541381nzd for ; Thu, 26 Jan 2006 15:42:02 -0800 (PST) Received: by 10.37.2.70 with SMTP id e70mr2005923nzi; Thu, 26 Jan 2006 15:42:02 -0800 (PST) Received: by 10.37.2.5 with HTTP; Thu, 26 Jan 2006 15:42:02 -0800 (PST) Message-ID: <8f2776cb0601261542t6b5f002al343ed6c0d78f840c@mail.gmail.com> Date: Thu, 26 Jan 2006 23:42:00 -0000 From: Jim Blandy To: NZG Subject: Re: remote connection crash, was frame theory Cc: gdb-patches@sourceware.org, Daniel Jacobowitz , Mark Kettenis In-Reply-To: <200601261726.11037.ngustavson@emacinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200601231438.26040.ngustavson@emacinc.com> <200601262240.k0QMe7SC026344@elgar.sibelius.xs4all.nl> <20060126224429.GA20076@nevyn.them.org> <200601261726.11037.ngustavson@emacinc.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00441.txt.bz2 On 1/26/06, NZG wrote: > On Thursday 26 January 2006 4:44 pm, Daniel Jacobowitz wrote: > > On Thu, Jan 26, 2006 at 11:40:07PM +0100, Mark Kettenis wrote: > > > To me, it looks like you're connecting to a buggy stub. > > > > He's connecting to basically a standard gdbserver, poised at > > the first instruction of the program. Memory has garbage > > and/or is invalid - no MMU so reading from garbage memory > > is a bit more serious than is typical for GDB. > righto, it crashes the remote kernel and sends my host into an infinite l= oop > in gdb. > > > The best thing here would be, if the stub can find out from > > the kernel what constitutes "valid" RAM, to refuse reads to > > it. Then ignore the ugliness when you type backtrace and > > don't have a stack yet - it's not real surprising that doesn't > > work! The PC is valid at this point, right? If there were clean Dwarf CFI for the entry point, marking it as the oldest frame, would that calm GDB down? That could be another approach.