Ethereal-dev: Re: [ethereal-dev] Possible crash problem in file.c

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 21 Jun 2000 11:05:49 -0700 (PDT)
> 1) The assignment to fdata->next should be protected by
> an assertion that fdata is not NULL.
> 
>        g_assert( fdata );

On most platforms (Linux, *BSD, Solaris, Win32, and probably others),
it's protected by the MMU - the program will crash when it tries to
dereference "fdata", and you can go into the debugger and see precisely
where it crashed *and* see the full call chain *and* see at least the
values of global variables, and possibly local ones, to give you more
information to figure out *why* the pointer was null.

Relying *solely* on assertions for debugging seems like programming with
one hand tied behind your back; a debugger lets you get a *lot* more
information than does an assertion, speeding up the process of
debugging.

If every single pointer dereference had a "g_assert()" checking that the
pointer isn't null, the code would probably be somewhere between 10% and
30% assertions.

> 2) The return value of g_mem_chunk_alloc() should be checked

The only reason it would return NULL is if you passed it a null pointer
(see the code, in "gmem.c"), and that can only occur if the program
using it has a bug - in which case the correct way to handle the error
is to dump core, so that you can use the debugger to figure out which
particular call is buggy, and why.

On most if not all platforms, said core dump (or, in the case of Win32,
Dr. Watson error) will occur when the program tries to dereference the
null pointer returned.

> 3) There should be an assertion at the top of wtap_dispatch_cb()
> that cf->plist_chunk is not NULL.
> 
>      g_assert( cf->plist_chunk );

See response to 1).