Ethereal-dev: RE: [Ethereal-dev] Questions on dfilter processing

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

From: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Tue, 9 Dec 2003 23:17:41 +0100
Hi Gilbert,

I added temporary debugging to semcheck.c, sttype-test.c and I realized that
dfw_semcheck() is called 115 times for one trace I have, although
colorfilters are disabled (I removed the file). I counted the occurrences of
dfw_semcheck() with a static guint. Some sample output:

#########################
dfw_semcheck(113): BEGIN
#########################
semcheck(271) - BEGIN
check_test(271) - BEGIN
check_test(271): (a)	sttype_test_get()
check_test(271): (b)	Succeeded! Now: switch(st_op) [12]
check_relation_LHS_FIELD(192): START
check_relation_LHS_FIELD(192)(matches, can_func, allow_partial, st_node,
st_arg1, st_arg2): START
a. type2 == STTYPE_UNPARSED:
	[<field:=FIELD>] <matches> [\]:=UNPARSED
fvalue_new(FT_STRING)
1. SLAB_ALLOC()
2. FTYPE_LOOKUP()
3. ft->new_value (not NULL)
3.1 ft->new_value(fv)
string_fvalue_new(fv = 0x10893610) of type FT_STRING - BEGIN
string_fvalue_new(fv = 0x10893610) of type FT_STRING - END
4. DONE!
string_fvalue_free(fv = 0x10893610) of type FT_STRING - BEGIN
string_fvalue_free(fv = 0x10893610) of type FT_STRING - END
fvalue_new(FT_BYTES)
1. SLAB_ALLOC()
2. FTYPE_LOOKUP()
3. ft->new_value (not NULL)
3.1 ft->new_value(fv)
4. DONE!
string_fvalue_free(fv = 0x10893610) of type FT_STRING - BEGIN
string_fvalue_free(fv = 0x10893610) of type FT_STRING - END
check_relation_LHS_FIELD(192)(matches, can_func, allow_partial, st_node,
st_arg1, st_arg2): END
check_relation_XXXXXXXX(192): END
check_test(271) - END
semcheck(271) - END

#########################
dfw_semcheck(113): END
#########################

Regards,

Olivier

| -----Original Message-----
| From: Gilbert Ramirez
| 
| On Mon, 2003-12-08 at 15:15, Biot Olivier wrote:
| > Hi List,
| > 
| > I have some doubts/questions on how the dfilter processing 
| works (maybe I
| > don't get all the items right). I added debug logging in
| > epan/dfilter/semcheck.c and I realized that dfw_semcheck() 
| is called for
| > every header field when a dfilter is evaluated.
| 
| It shouldn't be. dfw_semcheck() should only be called once, during the
| compilation of the dfilter string into a dfvm array. Can you give more
| detail if indeed you are seeing it called more than once?
| 
| > Now, I intend to compile and analyze the PCRE regular 
| expression only once
| > for every matches operator in a dfilter expression, by 
| adding the following
| > code to the check_relation_LHS_FIELD() function:
| > 
| > 	else if (type2 == STTYPE_STRING) {
| > 		s = stnode_data(st_arg2);
| > 		if (strcmp(relation_string, "matches") == 0) {
| 
| The relation_string was put there really for reporting 
| purposes. If you
| want to compare against it, you might consider using an enum value for
| quicker comparisons.

I'll replace the char * relation_string with an ENUM.

| > BUT... I fear that the conversion from a string to a 
| FT_PCRE happens more
| > than once. Is my assumption correct, or (hopefully) not?
| 
| I hope not. It should not be happening more than once.