Ethereal-dev: Re: Re: [Ethereal-dev] Re: ethereal bug

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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Tue, 25 Feb 2003 00:06:51 -0800
On Tue, Feb 25, 2003 at 08:55:29AM +0100, martin.regner@xxxxxxxxx wrote:
> 
> Brad Hards wrote:
> > Except, that both of them produce:
> > GLib-CRITICAL **: file ghash.c: line 138 (g_hash_table_lookup): assertion `hash_table != NULL' failed.
> > 
> 
> 
> The problem seems to be that ncp_req_eid_hash is NULL.
> I added some g_warning printouts in  ncp_eid_hash_lookup
> and ncp_hash_lookup (packet-ncp2222.inc)
> 
> When I opened the file I got the following output:
> 
> ncp_req_eip_hash_lookup  ncp_req_eid_hash=0224D098
> ncp_req_eip_hash_lookup  ncp_req_eid_hash=0224D098
> ncp_req_eip_hash_lookup  ncp_req_eid_hash=00000000
> 
> One thing to avoid the GTK-Critical printout is to add check if the pointer is null, and then return NULL. However I'm not sure if that
> is the best solution. 

It appears that "dissect_nds_request()" can call "ncp_eid_hash_lookup()"
even if "pinfo->fd->flags.visited" is TRUE, but that means it's called
after the first sequential pass - but the hash tables are freed after
that pass.

If so, then either

	1) the hash tables need *NOT* to be freed after the first
	   sequential pass

or

	2) the call to "ncp_eid_hash_lookup()" has to be done only if
	   "pinfo->fd->flags.visited" is false.

(BTW, in "dissect_ncp_reply()", "resolve_eid" is initially set to FALSE,
and never set to TRUE, so the "if (resolve_eid) { ... }" code is dead.)