[Top] [All Lists]

Re: new type of crash report?

To: Giuseppe Sacco <>
Subject: Re: new type of crash report?
From: "Kevin D. Kissell" <>
Date: Sun, 03 Feb 2008 18:10:24 +0100
In-reply-to: <1202054465.7035.20.camel@scarafaggio>
Original-recipient: rfc822;
References: <1202050578.7035.11.camel@scarafaggio> <> <1202054465.7035.20.camel@scarafaggio>
User-agent: Thunderbird (Windows/20071031)
Giuseppe Sacco wrote:
Hi Markus,

Il giorno dom, 03/02/2008 alle 16.52 +0100, Markus Gothe ha scritto:
You can always start with running run gdb at the read address
(ra: 0x2ac2bfdc), I'd also try listing 0x2ac2bffc.

Thanks for your reply. I will try to understand how to use gdb on this
context. (Any URI would be really appreciated.)
Anyway I now understood that a dbe is a data bus error, so probably this
is an error on the physical address, i.e. a kernel problem related to
the mapping between vertical and physical addresses. Is this correct?
That's correct.  You didn't say what processor you were running on, so it's hard to be more specific - there are some which have a bus error input pin that can be asserted by the system for other reasons - but in general it means that there's a data reference at 0x2ac2bffc whose valid translation goes to a bad address.  Generally, that address range is where shared libraries are mapped, so to find the instruction you want to run the program that caused the crash under gdb, set a breakpoint very early (e.g. main), run to the breakpoint, and disassemble the virtual address.  I find it interesting that the register value reported for register $10 is a reasonable data address shifted up by 32 bits.  It's possible that code would have a real reason to do that, but I can't help wonder if that isn't part of the problem. We may be looking at a 2-level bug here:  User(?) code screwing up a base register used for a load or store, and the OS failing to handle the upper reaches of the 64-bit address space correctly.


          Kevin K.
<Prev in Thread] Current Thread [Next in Thread>