> I have been able to confirm that cf->plist_chunk was 0x0.
"plist_chunk" is set in "open_cap_file()" if the open succeeds; it will
return NULL if "g_mem_chunk_new()" is passed a bad argument (either a
non-positive second argument or a third argument greater than or equal
to the second argument), otherwise it'll return a non-null value (unless
you're unlucky enough to be on a platform where dereferencing null
pointers doesn't cause a crash).
It seems unlikely, unless you have a compiler bug, that either of those
problems would occur, given that the second argument is
"sizeof(frame_data)" and the third argument is "FRAME_DATA_CHUNK_SIZE *
sizeof(frame_data)", and FRAME_DATA_CHUNK_SIZE is 1024.
It is set to NULL in "close_cap_file()".
So it appears that either
1) somehow invalid arguments are being passed to
"g_mem_chunk_new()"
or
2) somehow "wtap_dispatch_cb()" is being called when no capture
file is open.
This is a job for a debugger; if the capture file is closed, several
other members of the structure pointed to by "cf" will be NULL, e.g.
"cf->wth" and "cf->filename".
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.
If they're not null, perhaps somehow bad arguments are getting passed to
"g_mem_chunk_new()"; set a breakpoint in "open_cap_file()" right after
"g_mem_chunk_new()" is called, and see whether "cf->plist_chunk" is set
to zero right after "g_mem_chunk_new()" returns (i.e., if
"g_mem_chunk_new()" returned a null pointer).