At 10:11 PM 6/21/00, Ben Fowler wrote:
At 07:16 PM 6/21/00, Guy Harris wrote:
[ ... ]
If they're null, somehow it's being called when no capture file is open;
you should then try running Ethereal under a debugger, with a breakpoint
set in "close_cap_file()", and see if that's somehow getting called
while the file is still being read.
I am working on the basis that the problem is genuine and occurs
when calling Quit (Ctrl-Q) whilst a file read is happening.
I am fairly sure that the function file_quit_cmd_cb() in the file
gtk/main.c is closing the capture_file when the user selects
Quit from the file menu. When this happens, the reading routine
in file.c tries to read from a closed file.
Unless there is an obvious way to get that routine to bail out, it
might be a good idea to have file_quit_cmd_cb() stuff a suitable
USER_CANCELLED_READ value in the capture_file structure,
and have the read routine check this whenever it receives
control back from the event loop.
In support of actions like this, I have needed to note wherever
the capture_file structure might be modified. So far as I can
tell there is only one, and it is a global variable in gtk/main.c .
Leaving on one side the question of whether there ought to be support
for more than one Window/Capture_File, I found it desirable
to have a slightly longer and ostentatious name to distinguish
the global capture_file variable from any capture_filters, and of course
local pointers.
Here is a patch which converts the global cf to cfile.
As you know, it is difficult to be certain when making extensive
changes in many files to someone else's code that I have
a) caught them all, and,
b) not accidentally changed any other variable with the same name
but a different meaning.
I have taken great care, and checked my work as much as I can.
From my point of view, the sooner a change like this is done the
better as once a global variable has a unique name then one can
use simple tools like grep to keep it under control (point b).
Ben.
Attachment:
patch
Description: Binary data
--
Leedsnet - The information resource for Leeds and the West Riding
< URL:http://www.leedsnet.com/mobile/ >
