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.
Regards,
Kevin K.
|
|