Solaris 10 tshark “bus error” when reading some pcap files

Question

Can anyone provide me some insight what is the root cause of the following problem & how to fix it? (ie. Do it need to recompile tshark or just have the dependence updated?)

The version of tshark and its dependency are from the sunfreeware.com.

# uname -a
SunOS daisy 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Blade-1500 Solaris
# 
# tshark -r dhcp.pcap

...

229 159.632917 MasterIn_16:74:3c -> Broadcast    ARP 68 Who has 192.168.150.150?  Tell 192.168.150.192
230 160.003917 Cisco_51:01:db -> Spanning-tree-(for-bridges)_00 STP 64 RST. Root = 8192/152/00:11:bc:c3:94:00  Cost = 4  Port = 0x80cc
Bus Error (core dumped)

gdb indicate there is a Illegal instruction in the libcrypto.so.1.0.0

#0 0xfd4be44c in ?? () from /usr/local/lib/libwireshark.so.1 (gdb) r Starting program: /usr/local/bin/tshark [New LWP 1 ] warning: Lowest section in /usr/lib/libpthread.so.1 is .dynamic at 00000074 warning: Lowest section in /usr/lib/libthread.so.1 is .dynamic at 00000074 warning: Lowest section in /lib/libdl.so.1 is .hash at 000000b4 Program received signal SIGILL, Illegal instruction. 0xfc0cbd3c in _sparcv9_fmadd_probe () from /usr/local/ssl/lib/libcrypto.so.1.0.0 (gdb) tshark -v TShark 1.6.4 (SVN Rev Unknown from unknown) Copyright 1998-2011 Gerald Combs <[email protected]> and contributors. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled (32-bit) with GLib 2.25.13, with libpcap 1.2.0, with libz 1.2.5, without POSIX capabilities, without libpcre, without SMI, without c-ares, with ADNS, without Lua, without Python, with GnuTLS 2.8.6, with Gcrypt 1.4.6, without Kerberos, with GeoIP. Running on SunOS 5.10, with libpcap version 1.2.0, with libz 1.2.5.

Built using gcc 3.4.6. #

Answer 1

The root cause of the problem is probably that SPARC is the one remaining processor out there (or, at least, the one remaining processor used in general-purpose computers) that traps on unaligned accesses rather than supporting unaligned accesses, most people develop code on other processors and may not realize that you can't blithely dereference unaligned pointers, and some compilers don't warn about those dereferences (either because they're generating code for other processors and don't bother to do the check or don't bother to do the check at all) and even for the ones that do we aren't checking for those warnings. :-)

I.e., this is a Wireshark bug, it's just one that doesn't show up on most machines.

(That's probably different from the SIGILL problem, which is some other issue, perhaps an issue with gdb.)

Do you have a stack trace of the "bus error" crash? I'll see whether there are any alignment warnings coughed up by, for example, the Clang static analyzer.