> Anytime I run Ethereal (version 0.8.14) on my Redhat 6.1 system
> it locks up. I was running 0.8.9 which seemed to operate just fine.
> However, when I upgraded to the latest version, it started locking up on
> me. It seems to happen whenever my Win2000 laptop starts browsing
> shares on other Windows boxes. The FAQ makes mention of this problem,
> but doesn't say anything more than that the problem goes away
> with versions greater than 0.8.2....any ideas?
One idea is that there's more than one way in which Ethereal can lock
up, and this may well be a different one from the one mentioned in the
FAQ.
When it locks up, is it *just* capturing, or is it also displaying
packets as they arrive, or is it reading in a capture after you've
clicked "Stop" on the capture packet count window?
If it's one of the latter two, it could be a bug in a dissector where
the dissector goes into an infinite loop (rather than the libpcap
deficiency that was the original bug, and that we really *did* work
around in 0.8.3 or so - the workaround hasn't changed in ages, so it's
unlikely that this *particular* problem came back between 0.8.9 and
0.8.14).
When it's locked up, try sending it a SIGABRT signal, by doing
kill -ABRT <process ID of the Ethereal process>
(if there's only one Ethereal running, but two processes, try killing
the one that has the lower process ID, if the two process IDs are
numerically close; if one is very large and the other small, kill the
one with the larger number).
That *should* cause the Ethereal process in question to dump core; if
there's a "core" file in the directory in which you ran Ethereal, do
gdb ethereal core
(if the Ethereal binary isn't in the directory in which you ran
Ethereal, supply the pathname of that binary instead of just
"ethereal"), and then do "bt" when it prints the "(gdb)" prompt, and
send us the result.
Also, if this was during a capture, there will probably be a file in
"/tmp" or "/var/tmp" with a name beginning with "ether" and having a
bunch of other random characters after it, and with a recent
modification date; save that file - it's the capture file that Ethereal
was capturing. We may need it either to debug the problem or test the
fix, if it is (as I suspect it might be) a dissector problem.