Re: [Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault
8 Jun
2007
8 Jun
'07
12:10 a.m.
Samuel,
yes it is related to. The resolution of SER-263 was wrong and every test
like if (@select=="") has returned false, even the return value of
the select was empty string.
But, there is another problem I see in the config (including the example
script)...
There is difference between the (@select) test and (@select!="") one.
The latter returns false, if the select framework returns N/A value
(e.g. non present header/parameter).
Intended behaviour was: @X is @route[1].params.lr in this example
(as the tag must have value if present rfc3261 19.3)
lr parameter test result
not present @X false
!@X true
@X=="" FALSE*
@X!="" FALSE*
lr @X true
!@X false
@X=="" true
@X!="" false
lr=123 @X true
!@X false
@X=="" false
@X!="" true
As I see the from the example ser.cfg, the tests are done in the
(@to.tag=="") way, which won't work if the to.tag would return either
N/A or the tag value. But it seems it returns the empty string even if
not present, because it was previously working.
So I ask the community (especially TB potential members) do we want to
take care about the select N/A value differently, or shall we make it
equal to empty string?
Note, that if the answer is yes, it will be very hard to differentiate
between parameter not present and parameter without value - well the lr
parameter is handled internally, but what others?
If the anwser is no, keep special N/A value handling, the select must be
reviewed together with the ser.cfg, because (@to.tag=="") will be false
for every tag (because it must have value).
Michal
On Čt, 2007-06-07 at 13:56 +0200, samuel wrote:
Michal,
I've just post a question to users' list about not properly detecting
@to.tag=="".
Is this bug related to it??
Thanks,
Samuel.
2007/6/7, Michal Matyska (JIRA) < tracker(a)iptel.org>gt;:
[ http://tracker.iptel.org/browse/SER-263?page=all ]
Michal Matyska reopened SER-263:
--------------------------------
The way it is now resolved is wrong. If the select returns
empty string the script test if (@select=="") is false.
Using @select=~ "regexp" causes
segmentation fault
--------------------------------------------------
Key: SER-263
URL: http://tracker.iptel.org/browse/SER-263
Project: SER
Issue Type: Bug
Components: core, Selects
Affects Versions: 2.0, Ipteldorf
Environment: CVS head
Reporter: Michal Matyska
Assigned To: Michal Matyska
Priority: Minor
Fix For: 2.0, Ipteldorf
If the result of the select is empty string or it is
STR_STATIC_INIT (
e.g. @uri.type) the prepatation of left
operand (putting \0 behind the string) causes segmentation
fault .
Program received signal SIGSEGV, Segmentation
fault.
comp_str (op=11, left=0xbfad27a4, rtype=5, r=0x81932b0,
msg=0x81a1034) at
route.c:668
668
left->s[left->len]='\0';
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://tracker.iptel.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
8 Jun
8 Jun
10:16 a.m.
New subject: [Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault
IMHO,
I wouldn't "equalize" non-existent parameter with empty string. There are
header parameters (maddr,rport,isfocus) which may not have value and someone
(who knows?) might need to check for them. I would just not forbid this
option from the config file...
I would just use the @ and !@ uses for detecting presence or absence of
attributes and letting the == to check for the value once you know it
exists. It "complicates" a little bit config file but makes it clearer and I
think easier to debug.
So, for me it's fine changing example config files and documenting it.
my 0.02,
Samuel
2007/6/8, Michal Matyska <michal(a)iptel.org>rg>:
Samuel,
yes it is related to. The resolution of SER-263 was wrong and every test
like if (@select=="") has returned false, even the return value of
the select was empty string.
But, there is another problem I see in the config (including the example
script)...
There is difference between the (@select) test and (@select!="") one.
The latter returns false, if the select framework returns N/A value
(e.g. non present header/parameter).
Intended behaviour was: @X is @route[1].params.lr in this example
(as the tag must have value if present rfc3261 19.3)
lr parameter test result
not present @X false
!@X true
@X=="" FALSE*
@X!="" FALSE*
lr @X true
!@X false
@X=="" true
@X!="" false
lr=123 @X true
!@X false
@X=="" false
@X!="" true
As I see the from the example ser.cfg, the tests are done in the
(@to.tag=="") way, which won't work if the to.tag would return either
N/A or the tag value. But it seems it returns the empty string even if
not present, because it was previously working.
So I ask the community (especially TB potential members) do we want to
take care about the select N/A value differently, or shall we make it
equal to empty string?
Note, that if the answer is yes, it will be very hard to differentiate
between parameter not present and parameter without value - well the lr
parameter is handled internally, but what others?
If the anwser is no, keep special N/A value handling, the select must be
reviewed together with the ser.cfg, because (@to.tag=="") will be false
for every tag (because it must have value).
Michal
On Čt, 2007-06-07 at 13:56 +0200, samuel wrote:
Michal,
I've just post a question to users' list about not properly detecting
@to.tag=="".
Is this bug related to it??
Thanks,
Samuel.
2007/6/7, Michal Matyska (JIRA) < tracker(a)iptel.org>gt;:
[ http://tracker.iptel.org/browse/SER-263?page=all ]
Michal Matyska reopened SER-263:
--------------------------------
The way it is now resolved is wrong. If the select returns
empty string the script test if (@select=="") is false.
Using @select=~ "regexp" causes
segmentation fault
--------------------------------------------------
Key: SER-263
URL: http://tracker.iptel.org/browse/SER-263
Project: SER
Issue Type: Bug
Components: core, Selects
Affects Versions: 2.0, Ipteldorf
Environment: CVS head
Reporter: Michal Matyska
Assigned To: Michal Matyska
Priority: Minor
Fix For: 2.0, Ipteldorf
If the result of the select is empty string or it is
STR_STATIC_INIT (
e.g. @uri.type) the prepatation of left
operand (putting \0 behind the string) causes segmentation
fault .
Program received signal SIGSEGV, Segmentation
fault.
comp_str (op=11, left=0xbfad27a4, rtype=5, r=0x81932b0,
msg=0x81a1034) at
route.c:668
668
left->s[left->len]='\0';
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators:
http://tracker.iptel.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev 
11:27 a.m.
New subject: [Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault
Michal Matyska wrote:
Samuel,
yes it is related to. The resolution of SER-263 was wrong and every test
like if (@select=="") has returned false, even the return value of
the select was empty string.
But, there is another problem I see in the config (including the example
script)...
There is difference between the (@select) test and (@select!="") one.
The latter returns false, if the select framework returns N/A value
(e.g. non present header/parameter).
Intended behaviour was: @X is @route[1].params.lr in this example
(as the tag must have value if present rfc3261 19.3)
lr parameter test result
not present @X false
!@X true
@X=="" FALSE*
@X!="" FALSE*
lr @X true
!@X false
@X=="" true
@X!="" false
Shouldn't @X=="" return false in this case? (the parameter has no
value, not even empty one). To make this true the parameter should be
lr="" imho.
IMHO if you specify a value to test in the expression then the
parameter must have a value for the test to succeed. If you do not
specify any value in the expression then the presence of the parameter
should be sufficient for the test to succeed.
lr=123 @X true
!@X false
@X=="" false
@X!="" true
The rest seems fine to me.
As I see the from the example ser.cfg, the tests are
done in the
(@to.tag=="") way, which won't work if the to.tag would return either
N/A or the tag value. But it seems it returns the empty string even if
not present, because it was previously working.
As far as I can remember it used to work the way you describe (at
least I was using @route[1].params.lr in my configs to test for the
presence of the lr parameter some time ago.
So I ask the community (especially TB potential
members) do we want to
take care about the select N/A value differently, or shall we make it
equal to empty string?
No, we should not make it equal. We need to have a mechanism to test
for the presence of a parameter regardless its value and yet we need
to be able to test if a parameter is set to an empty string.
Note, that if the answer is yes, it will be very hard
to differentiate
between parameter not present and parameter without value - well the lr
parameter is handled internally, but what others?
In digest authentication this could be important. There the absence of
a parameter could change the way hash computations are done. The
presence of the same parameter, albeit with empty value has different
meaning.
If the anwser is no, keep special N/A value handling,
the select must be
reviewed together with the ser.cfg, because (@to.tag=="") will be false
for every tag (because it must have value).
Jan.
11:29 a.m.
New subject: [Serusers] [Serdev] [Tracker] Reopened: (SER-263) Using @select=~ "regexp" causes segmentation fault
Jan Janak wrote:
Shouldn't @X=="" return false in this
case? (the parameter has no
value, not even empty one). To make this true the parameter should be
lr="" imho.
IMHO if you specify a value to test in the expression then the
parameter must have a value for the test to succeed. If you do not
Errata: then the parameter must have a value and the value must be
equal for the test to succeed.
specify any value in the expression then the
presence of the parameter
should be sufficient for the test to succeed.
Jan.
6403
days inactive
6404
days old
3 comments
3 participants
participants (3)
-
Jan Janak -
Michal Matyska -
samuel