ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-users: Re: [ethereal-users] RH6.2 + 0.8.8 src = abit unstable; am I doing anything wron

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxxxxx>
Date: Tue, 9 May 2000 10:51:50 -0700
> ... but on trying to reopen the cap file,
> ethereal reads it in, sits and thinks for a while (no CPU usage) and then
> dies with a core dump.

As per the note in the README file:

	If Ethereal died on you with a 'segmentation violation', you can
	help the developers a lot if you have a debugger installed.  A
	stack trace can be obtained by using your debugger ('gdb' in
	this example), the ethereal binary, and the resulting core file. 
	Here's an example of how to use the gdb command 'backtrace' to
	do so.

	$ gdb ethereal core
	(gdb) backtrace
	..... prints the stack trace
	(gdb) quit
	$

can you show us a stack trace (so we have a better chance of figuring
out what routine caused it to crash)?

Also:

	if you're reading a saved capture file, please keep it around,
	as we may ask you for a copy of it (in case we can't diagnose
	the problem with just the stack trace);

	if this was what happened when you hit the "Stop" button on the
	capture dialog box (i.e., you hadn't gotten a chance to save the
	capture file), please check in "/tmp" and "/var/tmp" for a file
	whose name begins with "ether" and contains a bunch of random
	characters after that, as that'd probably be the capture in
	question - try reading that file in with Ethereal, as, if it
	dumps core, that's probably the capture in question, so you
	should save it (i.e., move it out of "/tmp" or "/var/tmp").