Ethereal-dev: Re: [ethereal-dev] problem with 'live' captures and latest CVS.

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

From: Gilbert Ramirez <gram@xxxxxxxxxx>
Date: Mon, 3 Apr 2000 10:25:56 -0500
On Mon, Apr 03, 2000 at 08:05:52AM -0500, Paul Wagland wrote:
> 
> Hi all,
> 
> (you will probably get sick of me soon :)
> 
> I have come across another problem with the latest CVS build. When I try to
> view the packets as they are captured, ethereal falls in a heap. This is
> easily reproducible in my environment. This one only started happening
> today.
> 
> Before I start trying to trace the problem, has anyone else seen this
> problem? Would anyone have a suggestion on where to start looking?
> 
> Till later,
> Paul
> 
> This is the stacktrace (from gdb) (just in case it helps someone...):
> ---
> #0  wtap_dispatch_cb (user=0x817a120 "x#\037\b\b", phdr=0x81f50d4,
> offset=40,
>     buf=0x81f3ba0 "\b") at file.c:666

That's interesting. What is on line 666 of your file.c? On mine, it's

  fdata->next = NULL;


Which is the first thing after allocating a frame_data. A few days ago we did
this:

  /* Allocate the next list entry, and add it to the list. */
  fdata = (frame_data *) g_malloc(sizeof(frame_data));

But now we do this:

/* Allocate the next list entry, and add it to the list. */
  fdata = g_mem_chunk_alloc(cf->plist_chunk);

It would appear that g_malloc returned a bad value. It probably
returned NULL to indicate "out of memory".

Can you use gdb to determine what the of fdata was, if you still
have the core file laying around? Or insert some code before line
666 to print the value of fdata, or test for NULL?

(send me private e-mail if you need help with this)

--gilbert