> > Maybe I should setup a build-enviroment for the Win-Port.....
It wasn't that hard - I set it up as a "Makefile" project, or something
such as that, in Visual C++ 6.0, which means it just runs "nmake" for
you, and, if you copy the resulting executable to the "Debug" directory
after building it, it'll let you run the debugger on it.
> For those more knowledgable about Win32, could this be an issue of
> compiling Ethereal as multi-threaded, but not glib and friends?
Perhaps it could be, but it's not.
It's an issue of me screwing up; I reproduced it on Boring Old FreeBSD.
My guess is that "close_cap_file()" is being called when the capture
file was already closed; I wasn't setting "cf->plist_chunk" after
destroying the memory chunk to which it pointed, so the second call to
"close_cap_file()" tried destroying an already-destroyed chunk, with
unfortunate results.
(I'm curious why the two calls; perhaps this is at least part of what
Doug Nazar was referring to in
http://ethereal.zing.org/lists/ethereal-dev/200004/msg00012.html
when he said
There also appear to be a lot of opens and closes.
.)
I've attached a patch, which I'll check in now.
Sorry about that....
Index: file.c
===================================================================
RCS file: /usr/local/cvsroot/ethereal/file.c,v
retrieving revision 1.178
diff -c -r1.178 file.c
*** file.c 2000/04/04 05:14:48 1.178
--- file.c 2000/04/06 05:58:37
***************
*** 209,216 ****
/* ...which means we have nothing to save. */
cf->user_saved = FALSE;
! if (cf->plist_chunk != NULL)
g_mem_chunk_destroy(cf->plist_chunk);
if (cf->rfcode != NULL) {
dfilter_destroy(cf->rfcode);
cf->rfcode = NULL;
--- 209,218 ----
/* ...which means we have nothing to save. */
cf->user_saved = FALSE;
! if (cf->plist_chunk != NULL) {
g_mem_chunk_destroy(cf->plist_chunk);
+ cf->plist_chunk = NULL;
+ }
if (cf->rfcode != NULL) {
dfilter_destroy(cf->rfcode);
cf->rfcode = NULL;
