Does the crash produce a core file? If so, you can produce a stack trace
using gdb. The stack trace will
be useful for us (the developers on ethereal-dev). Look at the README file
to see how to do that.
If ethereal hangs w/o crashing, you can cause it to drop core by sending
the ABRT signal to the process.
Find the process number via "ps ax | grep ethereal" and run "kill -ABRT
xxx" where xxx is the process number.
Once you have the core file, you can produce the stack trace.
--gilbert
"McNutt, Justin M." <McNuttJ@xxxxxxxxxxxx>@ethereal.com on 12/22/2000
09:08:52 AM
Sent by: ethereal-users-admin@xxxxxxxxxxxx
To: "'ethereal-users@xxxxxxxxxxxx'" <ethereal-users@xxxxxxxxxxxx>
cc:
Subject: [Ethereal-users] Ethereal 0.8.14 locks up on "large" captures.
Hey all,
I've been trying to do a capture on a link that has *very* high
utilization,
but I wind up having to take tiny ( < 5000 packet ) captures because the
larger capture files cause ethereal to lock up during the decode.
I'm running ethereal 0.8.14 with zlib 1.1.3, UCD SNMP 4.1.2, libpcap 0.5.2,
gimp 1.0.4, and glib and gtk+ 1.2.8 (both).
After ethereal crashes, if I rerun ethereal and try to open the
etherXXXX.... files in /tmp, it re-attempts to decode them and locks at the
same place.
I don't know that I want to make the capture files available, since they
contain live data from our network, but is there a way to get ethereal to
tell me at what point it's crashing?
Thanks!
Justin McNutt
Mizzou Telecom - A Unit of IATS
(573) 882-5183
Attempting to make a living at legitimate computing...
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users