From owner-freebsd-sparc64@FreeBSD.ORG Sat Aug 20 18:58:57 2005 Return-Path: X-Original-To: sparc64@FreeBSD.org Delivered-To: freebsd-sparc64@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F233D16A41F; Sat, 20 Aug 2005 18:58:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8151743D45; Sat, 20 Aug 2005 18:58:56 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.4/8.13.4) with ESMTP id j7KIwuoU048783; Sat, 20 Aug 2005 11:58:56 -0700 (PDT) (envelope-from marcel@xcllnt.net) In-Reply-To: <20050820182755.GA57524@xor.obsecurity.org> References: <20050819171555.GA45748@xor.obsecurity.org> <20050820025336.GA94049@xor.obsecurity.org> <3DBF403C-80AA-46B4-A57B-8B78F033E368@xcllnt.net> <20050820182755.GA57524@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D6502D2-02E7-4BAE-B3C1-AA6D4613C8BC@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Sat, 20 Aug 2005 11:58:55 -0700 To: Kris Kennaway X-Mailer: Apple Mail (2.734) Cc: marcel@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: kgdb still broken? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2005 18:58:57 -0000 On Aug 20, 2005, at 11:27 AM, Kris Kennaway wrote: > On Fri, Aug 19, 2005 at 11:28:14PM -0700, Marcel Moolenaar wrote: > >> On Aug 19, 2005, at 7:53 PM, Kris Kennaway wrote: >> >> >>> It's not making much sense of the backtrace though: >>> >>> (kgdb) bt >>> #0 doadump () at /usr/src.6/sys/kern/kern_shutdown.c:233 >>> #1 0x00000000c006a728 in db_fncall (dummy1=0, dummy2=0, dummy3=11, >>> dummy4=0x16e9a41a0 "") >>> at /usr/src.6/sys/ddb/db_command.c:486 >>> #2 0x00000000c006a434 in db_command (last_cmdp=0xc040f940, >>> cmd_table=0x0, aux_cmd_tablep=0xc03c8dc8, >>> aux_cmd_tablep_end=0xc03c8de0) at /usr/src.6/sys/ddb/ >>> db_command.c:401 >>> #3 0x00000000c006a558 in db_command_loop () at /usr/src.6/sys/ddb/ >>> db_command.c:452 >>> #4 0x00000000c006d0b8 in db_trap (type=1855603632, code=0) at /usr/ >>> src.6/sys/ddb/db_main.c:221 >>> #5 0x00000000c018d208 in kdb_trap (type=107, code=0, >>> tf=0x16e9a4630) at /usr/src.6/sys/kern/subr_kdb.c:473 >>> #6 0x00000000c02f6b4c in trap (tf=0x16e9a4630) at /usr/src.6/sys/ >>> sparc64/sparc64/trap.c:307 >>> #7 0x00000000c0048fe0 in tl1_trap () >>> #8 0x00000000c0048fe0 in tl1_trap () >>> Previous frame identical to this frame (corrupt stack?) >>> >>> Where ddb showed that the panic correctly (see my mail to -current >>> entitled 'panic: uma_small_alloc: free page still has mappings!'). >>> >> >> How can you compare this backtrace with the one in the email. This >> backtrace is the result of a trap, not a panic. For a panic, KDB >> is entered via kdb_enter(), not kdb_trap() as it is in this case. >> > > Regardless, this is what kgdb informed me was the backtrace for the > same thread that panicked and I traced with DDB and gdb53. I guess I just don't understand what's you're saying then. The backtrace above clearly and reliably tells me that the core was created by calling doadump() from within DDB. Such a backtrace cannot be obtained from within DDB itself. I don't know what you get with gdb53, but it should give you the same backtrace, unless it shows the backtrace of a different thread or you were working on a different core file altogether. > I mean that 'info threads' doesn't work in gdb53, which is the only > offline debugger one can use on sparc64 that obtains more or less > reliable traces. What exactly is unreliable about backtraces in kgdb? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net