Help! SIGBUS (object specifc hardware error)
Mike Mowbray
I'd immediately suspect a data alignment problem.
But dbx says it was a SIGBUS (object specific hardware error).
This has happened to me both on Solaris 5.6 and Solaris-8.
On Solaris 5.6, "man siginfo" says:
SIGBUS BUS_ADRALN invalid address alignment
BUS_ADRERR non-existent physical address
BUS_OBJERR object specific hardware error
but doesn't explain BUS_OBJERR any further.
So I go onto a Solaris-8 machine, where I eventually find
"man __sparc_utrap_install" which says a bit more:
UT_DATA_ERROR, UT_INSTRUCTION_ERROR
A valid mapping exists, and both user privilege and
the type of access are allowed, but an unrecoverable
error occurred in attempting the access, for a data or
instruction access, respectively. %l1 will contain
either BUS_ADDRERR or BUS_OBJERR.
I interpret this to mean that my program is in fact doing nothing
wrong. Rather, something went bad in the Solaris kernel when
trying to fetch an instruction. (Presumably the problem was in the
virtual memory subsystem when it tried to bring in a text page?)
Questions:
1) Am I right to interpret "object specific hardware error"
in this way? Is it indeed a failure in the Solaris kernel
to access an instruction in my program? If not, then could
someone please explain more about what BUS_OBJERR means?
2) What could be causing it? Is it a Solaris kernel bug?
3) How can I fix it, or else debug the problem further?
Thanks in advance for any help.
- MikeM.
Casper H.S. Dik - Network Security Engineer
Mike Mowbray <mi...@ot.com.au> writes:
>I interpret this to mean that my program is in fact doing nothing
>wrong. Rather, something went bad in the Solaris kernel when
>trying to fetch an instruction. (Presumably the problem was in the
>virtual memory subsystem when it tried to bring in a text page?)
I don't think that conclusion is justified just yet.
>Questions:
> 1) Am I right to interpret "object specific hardware error"
> in this way? Is it indeed a failure in the Solaris kernel
> to access an instruction in my program? If not, then could
> someone please explain more about what BUS_OBJERR means?
It's an error returned by software somewhere deep down the VM system's
hat layer; without knowledge of the mapping at the address, how it was
accessed, it's hard to tell what really is the matter.
> 3) How can I fix it, or else debug the problem further?
Start by finding out which address is giving the problem, which instruction
is using the address and how.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Mike Mowbray
> Mike Mowbray <mi...@ot.com.au> writes:
>
> >>I interpret this to mean that my program is in fact doing nothing
> >>wrong. Rather, something went bad in the Solaris kernel when
> >>trying to fetch an instruction. (Presumably the problem was in the
> >>virtual memory subsystem when it tried to bring in a text page?)
>
> > I don't think that conclusion is justified just yet.
>
> >>Questions:
> >>
> >> 1) Am I right to interpret "object specific hardware error"
> >> in this way? Is it indeed a failure in the Solaris kernel
> >> to access an instruction in my program? If not, then could
> >> someone please explain more about what BUS_OBJERR means?
>
> > It's an error returned by software somewhere deep down the VM
> > system's hat layer;
Pardon my ignorance... what is the "hat" layer?
> > without knowledge of the mapping at the address, how it was
> > accessed, it's hard to tell what really is the matter.
>
> >> 3) How can I fix it, or else debug the problem further
> Start by finding out which address is giving the problem, which
> instruction is using the address and how.
Here's what I see under dbx:
> . t@3982 (l@3983) terminated by signal BUS (object specific hardware error)
>
> (dbx) where
> current thread: t@3982
> =>[1] scpChBuf::extract_line(0x9dc11a70, 0x9dc11a78, 0x9dc11b88, 0x9c83d872,
>
> 0x9dc11a70, 0x9dc11d38), at 0x12a6ac
> [2] TSACdb_Jstream::run_scan(0x1, 0x9cc4e000, 0x9dc11af4, 0x9dc11c48,
> 0x9dc11b88, 0x0), at 0x8a84c
> [3] TSACdb_JournalFile_Gzipper::doit_fg(0x9dc11c7c, 0x9dc11cf0,
> 0x9dc11d38,
> 0x9dc11cf4, 0x9cc4e000, 0x3baa63bc), at 0x964c8
> [4] tsacdb_bg_gzip_startfn(0x1e6bc30, 0x104e000, 0x3baa63bc, 0x9bc00000,
> 0x9dc11d38, 0xef666bf0), at 0x96710
> (dbx)
> (dbx) regs
> current thread: t@3982
> current frame: [1]
> g0-g3 0x00000000 0x001b9000 0x00000002 0x0000007a
> g4-g7 0x0000007a 0x00000000 0x00000000 0x9dc11dd8
> o0-o3 0x9c83e000 0x00000000 0x9cc4e000 0x00000000
> o4-o7 0x00000000 0x00000000 0x9dc119a8 0x0008a618
> l0-l3 0x00000000 0x00000000 0x00000000 0x00000000
> l4-l7 0x00000000 0x00000000 0x00000000 0x00000000
> i0-i3 0x9dc11a70 0x9dc11a78 0x9dc11b88 0x9c83d872
> i4-i7 0x9dc11a70 0x9dc11d38 0x9dc11a10 0x0008a84c
> y 0x00000000
> psr 0xfe901002
> pc 0x0012a6ac:extract_line+0x3c ldsb [%o0], %o1
> npc 0x0012a694:extract_line+0x24 cmp %o1, 0xa
> (dbx)
> (dbx)
>
> A brief disassembly around address 0x12a6ac shows:
>
> 0x0012a6a0: extract_line+0x0030: add %o0, 0x1, %o0
> 0x0012a6a4: extract_line+0x0034: cmp %o0, %o2
> 0x0012a6a8: extract_line+0x0038: blu,a extract_line+0x24
> => 0x0012a6ac: extract_line+0x003c: ldsb [%o0], %o1
> 0x0012a6b0: extract_line+0x0040: ba extract_line+0x8c
> 0x0012a6b4: extract_line+0x0044: add %fp, -0x8, %o0
> 0x0012a6b8: extract_line+0x0048: add %o0, 0x1, %i2
> 0x0012a6bc: extract_line+0x004c: cmp %i2, %o2
> 0x0012a6c0: extract_line+0x0050: bgeu extract_line+0x68
> 0x0012a6c4: extract_line+0x0054: mov %i1, %o0
>
> So the program looks ok, at least as far as I can tell.
Address 0x9c83e000 from which the ldsb instruction is trying to read is
(in theory) from a memory-mapped journal file. Mmapped files are usually not
stored in a core file so I can't access that address from dbx. (The core
file is from a customer site, and the database was restarted immediately
after the core dump so I can't get the original journal files.)
This particular section of code is only run by the program occasionally.
So the possibility (suggested by someone else who kindly responded to my post)
is that the problem may be a bus timeout as a result of a pagefault when
trying
to load the ldsb instruction. But if so, I'm surprised to see that happening
from an executable file which is on a local ufs filesystem.
Tks.
- MikeM.
chad schrock
Mike Mowbray wrote:
> "Casper H.S. Dik - Network Security Engineer" wrote:
> > Mike Mowbray <mi...@ot.com.au> writes:
> > >>Questions:
> > >>
> > >> 1) Am I right to interpret "object specific hardware error"
> > >> in this way? Is it indeed a failure in the Solaris kernel
> > >> to access an instruction in my program? If not, then could
> > >> someone please explain more about what BUS_OBJERR means?
> >
> > > It's an error returned by software somewhere deep down the VM
> > > system's hat layer;
>
> Pardon my ignorance... what is the "hat" layer?
Mike, the HAT layer is the "hardware address translation" layer.
Basically, the HAT layer is very low-level part of the virtual
memory system. HAT information describes how a memory page
is mapped on the physical side of the VM (i.e. RAM).
(There is a lot of in-depth info about this in "Solaris
Internals")
chad
--
chad at radix dot net