Greetings,
I recently deployed 1.5.0 and was thrilled to have the opportunity to use the new sqlops module for a purpose that required a lot of custom database logic, but unfortunately had to roll back to 1.4.4 because a lot of stuff seemed to be broken in the 'dialog' module. I refuse to believe that the 'dialog' module was released in such a broken state, so I am thinking I am problem is that I am neglecting something very important or that there are some omissions in the documentation.
System is CentOS 64-bit on a dual-CPU quad-core setup with 8 GB of RAM.
Two fundamental problems:
1) get_profile_size() on profiles with no "values" (i.e. inside the enumerated "profiles_no_value" modparam) crashes.
This problem also exists on 1.4.4. I have not tried other 1.4.x releases.
So, I have:
modparam("dialog", "enable_stats", 1) modparam("dialog", "hash_size", 65536) modparam("dialog", "rr_param", "dlgcor") modparam("dialog", "dlg_flag", 2) modparam("dialog", "default_timeout", 28800) modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "db_mode", 0) modparam("dialog", "profiles_no_value", "global") modparam("dialog", "profiles_with_value", "user")
And then, in my INVITE handler for inbound routes:
# Set dialog construction flag.
setflag(2);
# Add this dialog to the global call count profile.
set_dlg_profile("global");
# Add this dialog to a per-customer dialog profile.
set_dlg_profile("user", "$avp(S:user_id)");
# Put out some debugging values for global and customer profiles.
get_profile_size("global", "$var(global_dialog_count)");
get_profile_size("user", "$avp(S:user_id)", "$var(customer_dialog_count)");
The first get_profile_size() statement crashes--the one that refers to the profile without values.
According to the GDB backtrace, the crash occurs at modules/dialog/dialog.c:701:
if(sp_dest->setf(msg, &sp_dest->pvp, (int)EQ_T, &val)<0) { LM_ERR("setting profile PV failed\n"); return -1; }
The cause is that sp_dest is NULL here. I have determined that the value of 'result' in w_get_profile_size() as passed into this prototype:
static int w_get_profile_size(struct sip_msg *msg, char *profile, char *value, char *result)
is NULL.
I would conclude from this - not being a developer - that the root cause is that the config file/route script lexer does not properly distinguish between the value-less and with-value argument combination of get_profile_size() that can occur.
A workaround is possible by setting my 'global' profile to be "with values" as well and using a bogus value key like "1" that is always the same. However, I do not think this should be happening.
2) The second problem only occurs in 1.5.0 and not in 1.4. It is much more serious.
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
---
I find it hard to believe that the 'dialog' module in 1.5.0 was released with such regressions, and cannot find anything in the devel list archives or the tracker suggesting that this behaviour has been elsewhere. My only conclusion is that either I am doing something wrong or that there is a problem with my environment. Admittedly, I have not tried reproducing these issues in 32-bit library environment and perhaps should.
Please help!
-- Alex
Alex Balashov wrote:
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
I should add that this occurs in all db_modes and with all dialog correlation options, regardless of whether I use the LR cookie.
2009/4/7 Alex Balashov abalashov@evaristesys.com:
- The second problem only occurs in 1.5.0 and not in 1.4. It is much
more serious.
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
I confirm it, and already sent a mail about it.
Daniel and Iñaki,
Thank you for your confirmation and acknowledgment of the second problem, but I am still wondering about the first. That's the one where get_profile_size() on profiles without values crashes. Anything on that?
Thanks!
Iñaki Baz Castillo wrote:
2009/4/7 Alex Balashov abalashov@evaristesys.com:
- The second problem only occurs in 1.5.0 and not in 1.4. It is much
more serious.
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
I confirm it, and already sent a mail about it.
On 04/07/2009 11:53 AM, Iñaki Baz Castillo wrote:
2009/4/7 Alex Balashov abalashov@evaristesys.com:
- The second problem only occurs in 1.5.0 and not in 1.4. It is much
more serious.
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
I confirm it, and already sent a mail about it.
IIRC, for usage with dlg_manage() was working. Can you confirm it?
Cheers, Daniel
If I understood the docs correctly and tried it correctly, it definitely does not work.
-- Sent from mobile device
On Apr 9, 2009, at 5:25 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 04/07/2009 11:53 AM, Iñaki Baz Castillo wrote:
2009/4/7 Alex Balashov abalashov@evaristesys.com:
- The second problem only occurs in 1.5.0 and not in 1.4. It is
much more serious.
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
I confirm it, and already sent a mail about it.
IIRC, for usage with dlg_manage() was working. Can you confirm it?
Cheers, Daniel
-- Daniel-Constantin Mierla http://www.asipto.com/
On 04/09/2009 01:17 PM, Alex Balashov wrote:
If I understood the docs correctly and tried it correctly, it definitely does not work.
I understood that from you, I wanted to get Inaki's input because he reported some time before and I postponed the investigation because he said it works with the dlg_manage() but not with the flag.
Thanks, Daniel
-- Sent from mobile device
On Apr 9, 2009, at 5:25 AM, Daniel-Constantin Mierla miconda@gmail.com wrote:
On 04/07/2009 11:53 AM, Iñaki Baz Castillo wrote:
2009/4/7 Alex Balashov abalashov@evaristesys.com:
- The second problem only occurs in 1.5.0 and not in 1.4. It is
much more serious.
It would appear that the dialogs are not actually being inserted into the profiles - either the global or the per-user ones. I can see from the debug logs that the dialogs are being tracked because I set the dialog construction flag (2). I have also tried using dlg_manage(). However, get_profile_size(...) always returns 0 no matter what I do.
I confirm it, and already sent a mail about it.
IIRC, for usage with dlg_manage() was working. Can you confirm it?
Cheers, Daniel
-- Daniel-Constantin Mierla http://www.asipto.com/
Kamailio (OpenSER) - Users mailing list Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users http://lists.openser-project.org/cgi-bin/mailman/listinfo/users
2009/4/9 Daniel-Constantin Mierla miconda@gmail.com:
On 04/09/2009 01:17 PM, Alex Balashov wrote:
If I understood the docs correctly and tried it correctly, it definitely does not work.
I understood that from you, I wanted to get Inaki's input because he reported some time before and I postponed the investigation because he said it works with the dlg_manage() but not with the flag.
Yes, using the flag it just didn't work at all. Using dlg_manage() it worked. However I saw duplicate dialog entries (in both memory and DB table). Profiles don't work for me at all.
However I was testing it in a host for a project in my job and I cannot re-check it until April 14 (after holidays).
I'll try to get some time right now and check it in my personal server, and will comment here.
Regards.
2009/4/9 Iñaki Baz Castillo ibc@aliax.net:
Yes, using the flag it just didn't work at all. Using dlg_manage() it worked. However I saw duplicate dialog entries (in both memory and DB table). Profiles don't work for me at all.
Forget the above, now I've re-checked it:
---- Kamailio rev 5772
modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "db_mode", 1) ----
I've checked basically the following two cases:
a) setflag(FLAG_DIALOG); set_dlg_profile("inbound");
b) dlg_manage(); set_dlg_profile("inbound");
In both cases I add:
[[ in-dialog section ]] is_in_profile("inbound")) xlog("L_CRIT", "*********** this request belongs to a inbound call\n"); if(dlg_isflagset("1")) xlog("L_CRIT", "*********** Dialog Flag is SET \n");
Results:
a)
- Dialog entries are created correctly in memory and DB.
- Dialog profiles are not created: profile:: name=inbound value= count=0
- is_in_profile("inbound")) obviously doesn't work.
- if(dlg_isflagset("1")) doesnt' work for in_dialog request (it just works if I check it in the initial INVITE request after setting it, so it behaves as a script flag).
b)
- Dialog entries are created correctly in memory and DB.
- Dialog profiles are correctly created: profile:: name=inbound value= count=1
- is_in_profile("inbound")) doesn't work for in-dialog requests, neither in the initial INVITE after setting: set_dlg_profile("inbound");
- if(dlg_isflagset("1")) doesnt' work for in_dialog request (it just works if I check it in the initial INVITE request after setting it, so it behaves as a script flag).
There are some things I son't know (documentation is not very extended). For example, I don't know if I must use dlg_manage() when processing in-dialog requests, perhaps it's enough with running this function when proccesing the initial request? Also, the order in which functions as dlg_manage() and set_dlg_profile() is not documented. Doesn't it matter?
Regards.
Thanks for detailed report. Hopefully I fixed all issues. Please find attached a patch which includes the one I sent previously for the crash reported by Alex. If all ok I will fix on 1.5 branch.
Cheers, Daniel
On 04/09/2009 02:40 PM, Iñaki Baz Castillo wrote:
2009/4/9 Iñaki Baz Castillo ibc@aliax.net:
Yes, using the flag it just didn't work at all. Using dlg_manage() it worked. However I saw duplicate dialog entries (in both memory and DB table). Profiles don't work for me at all.
Forget the above, now I've re-checked it:
Kamailio rev 5772
modparam("dialog", "dlg_match_mode", 1) modparam("dialog", "db_mode", 1)
I've checked basically the following two cases:
a) setflag(FLAG_DIALOG); set_dlg_profile("inbound");
b) dlg_manage(); set_dlg_profile("inbound");
In both cases I add:
[[ in-dialog section ]] is_in_profile("inbound")) xlog("L_CRIT", "*********** this request belongs to a inbound call\n"); if(dlg_isflagset("1")) xlog("L_CRIT", "*********** Dialog Flag is SET \n");
Results:
a)
Dialog entries are created correctly in memory and DB.
Dialog profiles are not created: profile:: name=inbound value= count=0
is_in_profile("inbound")) obviously doesn't work.
if(dlg_isflagset("1")) doesnt' work for in_dialog request (it just
works if I check it in the initial INVITE request after setting it, so it behaves as a script flag).
b)
Dialog entries are created correctly in memory and DB.
Dialog profiles are correctly created: profile:: name=inbound value= count=1
is_in_profile("inbound")) doesn't work for in-dialog requests,
neither in the initial INVITE after setting: set_dlg_profile("inbound");
- if(dlg_isflagset("1")) doesnt' work for in_dialog request (it just
works if I check it in the initial INVITE request after setting it, so it behaves as a script flag).
There are some things I son't know (documentation is not very extended). For example, I don't know if I must use dlg_manage() when processing in-dialog requests, perhaps it's enough with running this function when proccesing the initial request? Also, the order in which functions as dlg_manage() and set_dlg_profile() is not documented. Doesn't it matter?
Regards.
On Tuesday 07 April 2009, Alex Balashov wrote:
[..] Two fundamental problems:
- get_profile_size() on profiles with no "values" (i.e. inside the
enumerated "profiles_no_value" modparam) crashes.
This problem also exists on 1.4.4. I have not tried other 1.4.x releases. [..]
Hi Alex,
at first i thought that this problem could be caused from the recent changed in the pv code that was done in preparations for the sr merge. But if this also happens in the 1.4.4 version, this is not possible.
According to the GDB backtrace, the crash occurs at modules/dialog/dialog.c:701:
if(sp_dest->setf(msg, &sp_dest->pvp, (int)EQ_T, &val)<0) { LM_ERR("setting profile PV failed\n"); return -1; }The cause is that sp_dest is NULL here. I have determined that the value of 'result' in w_get_profile_size() as passed into this prototype:
static int w_get_profile_size(struct sip_msg *msg, char *profile, char *value, char *result)
is NULL.
Are you sure that really result is NULL here? I'm not an expert in this dialog code, but i'd think that "value" should be null in profile without value. This is also the condition that is checked here:
pve = (pv_elem_t *)value; if ( pve!=NULL && ((struct dlg_profile_table*)profile)->has_value) {...}
I would conclude from this - not being a developer - that the root cause is that the config file/route script lexer does not properly distinguish between the value-less and with-value argument combination of get_profile_size() that can occur.
Yes, could be possible that the fixup function is not correct here.
A workaround is possible by setting my 'global' profile to be "with values" as well and using a bogus value key like "1" that is always the same. However, I do not think this should be happening.
Cheers,
Henning
Henning Westerholt wrote:
Are you sure that really result is NULL here? I'm not an expert in this dialog code, but i'd think that "value" should be null in profile without value. This is also the condition that is checked here:
I'm positive. That's the whole mystery.
I would conclude from this - not being a developer - that the root cause is that the config file/route script lexer does not properly distinguish between the value-less and with-value argument combination of get_profile_size() that can occur.
Yes, could be possible that the fixup function is not correct here.
That is my conclusion as well. I believe that it is making 'result' NULL instead of 'value.'
On Wednesday 08 April 2009, Alex Balashov wrote:
Are you sure that really result is NULL here? I'm not an expert in this dialog code, but i'd think that "value" should be null in profile without value. This is also the condition that is checked here:
I'm positive. That's the whole mystery.
I compared to some other module logic which also used optional parameters. I think that the function signature is probably wrong. The optional parameter should be always the last one(s), as its not possible to ommit a parameter from the middle of the given list. So instead of
get_profile_size(profile,[value],size) it should be get_profile_size(profile, size, [value])
Normally the cfg parser can not recognize the semantics of the parameters, i just gives them in to the fixup function which tries to parse them.
Henning
Henning Westerholt wrote:
The optional parameter should be always the last one(s), as its not possible to ommit a parameter from the middle of the given list.
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
On Wednesday 08 April 2009, Alex Balashov wrote:
The optional parameter should be always the last one(s), as its not possible to ommit a parameter from the middle of the given list.
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
Normally there is not that much magic, its a simple array of parameters that get filled, and then the module fixup functions are called for each of them.
sr_module.h: typedef int (*cmd_function)(struct sip_msg*, char*, char*, char*, char*, char*, char*);
But i did not wrote this code, perhaps one of the authors can comment here too.
Cheers,
Henning
Yeah, I know. I just figured I was missing some of the erudite PV magic in the fixup functions I was looking at, and that it is somehow able to tell whether the parameter in the middle is optional or not via some sort of crude scheme. Your interpretation confirms my suspicion that it in fact cannot.
Henning Westerholt wrote:
On Wednesday 08 April 2009, Alex Balashov wrote:
The optional parameter should be always the last one(s), as its not possible to ommit a parameter from the middle of the given list.
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
Normally there is not that much magic, its a simple array of parameters that get filled, and then the module fixup functions are called for each of them.
sr_module.h: typedef int (*cmd_function)(struct sip_msg*, char*, char*, char*, char*, char*, char*);
But i did not wrote this code, perhaps one of the authors can comment here too.
Cheers,
Henning
Hello,
never used this profile thing from dialog, but having a parameter in the middle being optional is strange. Please try attached patch and let me know if ok.
Cheers, Daniel
On 04/08/2009 03:42 PM, Alex Balashov wrote:
Yeah, I know. I just figured I was missing some of the erudite PV magic in the fixup functions I was looking at, and that it is somehow able to tell whether the parameter in the middle is optional or not via some sort of crude scheme. Your interpretation confirms my suspicion that it in fact cannot.
Henning Westerholt wrote:
On Wednesday 08 April 2009, Alex Balashov wrote:
The optional parameter should be always the last one(s), as its not possible to ommit a parameter from the middle of the given list.
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
Normally there is not that much magic, its a simple array of parameters that get filled, and then the module fixup functions are called for each of them.
sr_module.h: typedef int (*cmd_function)(struct sip_msg*, char*, char*, char*, char*, char*, char*);
But i did not wrote this code, perhaps one of the authors can comment here too.
Cheers,
Henning
Alex Balashov wrote:
Henning Westerholt wrote:
The optional parameter should be always the last one(s), as its not possible to ommit a parameter from the middle of the given list.
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
But, you know, this wasn't a problem in earlier releases like 1.3.x and 1.4.0, I think. I have certainly used value-less profiles before just fine. That's the only thing I'm still hung up on.
On Wednesday 08 April 2009, Alex Balashov wrote:
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
But, you know, this wasn't a problem in earlier releases like 1.3.x and 1.4.0, I think. I have certainly used value-less profiles before just fine. That's the only thing I'm still hung up on.
The dialog profile stuff was introduced in 1.4.0 i think, and in the respective place in dialog.c there were only one bugfix for a crash (reported from you) in the diff between 1.4.0 and 1.4.4.
Cheers,
Henning
Do you have any ETA on when a patch can be produced for this and the get_profile_size() == 0 problem?
Henning Westerholt wrote:
On Wednesday 08 April 2009, Alex Balashov wrote:
That's what I thought too, and wondered how the config lexer and fixup functions magically get around this problem.
But, you know, this wasn't a problem in earlier releases like 1.3.x and 1.4.0, I think. I have certainly used value-less profiles before just fine. That's the only thing I'm still hung up on.
The dialog profile stuff was introduced in 1.4.0 i think, and in the respective place in dialog.c there were only one bugfix for a crash (reported from you) in the diff between 1.4.0 and 1.4.4.
Cheers,
Henning
-
Alex Balashov -
Daniel-Constantin Mierla -
Henning Westerholt -
Iñaki Baz Castillo