Giuseppe Sacco wrote:
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.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? Regards, Kevin K. |