Comment # 8
on bug 11172
from Guy Harris
(In reply to Alexander Wetzel from comment #7)
> But as I understand the build log it's a segfault.
Until recently, all you could tell from the build log was that it was
*something* that caused a core dump; it could have been SIGSEGV or SIGBUS or
SIGABRT or....
Now, we at least catch the crash signal, and the latest build reports it's a
"Bus Error", i.e. SIGBUS, which:
http://docs.oracle.com/cd/E36784_01/html/E36873/siginfo.h-3head.html#REFMAN3Fsiginfo.h-3head
can be caused by "invalid address alignment", "non-existent physical address",
"object specific hardware error", or "user process uncorrectable memory error".
"user process uncorrectable memory error" is unlikely to be reproducible, so
that's probably not it.
"object specific hardware error" usually means, as I remember, "I/O error
trying to resolve a page fault", which is also unlikely to be reproducible.
"non-existent physical address" shouldn't happen for pages resident in main
memory; it might happen if you've memory-mapped I/O space, but that's not what
we're doing.
So it's probably "invalid address alignment", which you're probably not going
to see on anything other than SPARC (definitely not x86 - 32-bit or 64-bit - as
no OS I know of enables alignment faults; not System/3x0 - 32-bit or 64-bit -
either; I think PPC/Power ISA - 32-bit and 64-bit - handles unaligned
operations these days, at least if it doesn't cross a page boundary; I think
newer ARM might do so as well; I'm not sure about PA-RISC or MIPS).
I'll see if I can get the script that wraps execution of tshark to run a
debugger and get a stack trace if it finds a core file.
You are receiving this mail because:
- You are watching all bug changes.