THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Nuno Miguel Reis (nmreis)
Attached to Project - sip-router
Summary - CRASH: segmentation fault on module db_cluster with postgres
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - High
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - kamailio segfaults when using db_cluster/postgres and sip_trace.
It appears to work fine with some other lighter queries.
Please find attached the usual required data with the full backtrace.
Let me know if anything else is needed.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=476
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Fred Posner (qxork)
Attached to Project - sip-router
Summary - Documentation Incorrect
Task Type - Bug Report
Category - dialog
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Low
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - Documentation in Dialog module lists items, such as:
5.24. caller_contact_column (string)
The column name in the database to store the caller's contact uri.
Default value is “from_contact”.
Example 1.24. Set caller_contact_column parameter
...
modparam("dialog", "caller_contact_column", "column_name")
...
In the database, the default column appears to be "caller_contact"
User on irc reports the following:
" [modparam.c:152]: set_mod_param_regex(): set_mod_param_regex: parameter <caller_contact_column> of type <1> not found in module <dialog>"
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=475
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hello,
I believe I have found a bug in the xavp code (or a module that manipulates them - most likely the usrloc "ulattrs" feature), but I don't understand some bits of the xavp structure.
FYI the code I am running isn't master, it's from branch 4.1 plus a backport of my ulattrs from DB patch (http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=commit;h=22b559cb…).
Basically the linked list of xavp values links back to the top and creates an infinite loop when searching/inserting/deleting etc.
(gdb) bt
#0 0x0000000000544235 in xavp_get_internal (name=0x7fbac95d11f8, list=0x7fbaae036248, idx=0, prv=0x0) at xavp.c:267
#1 0x0000000000544325 in xavp_get_by_index (name=0x7fbac95d11f8, idx=0, start=0x7fbaae036248) at xavp.c:288
#2 0x00007fbac3316074 in pv_get_xavp (msg=0x7fbac961f958, param=0x7fbac95d1638, res=0x7fff99ae69d0) at pv_xavp.c:133
#3 0x00000000004995c8 in pv_get_spec_value (msg=0x7fbac961f958, sp=0x7fbac95d1620, value=0x7fff99ae69d0) at pvapi.c:1266
#4 0x00000000004c8c68 in rv_defined (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rv=0x7fbac95d1618, cache=0x0) at rvalue.c:1859
#5 0x00000000004c8d1b in int_rve_defined (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rve=0x7fbac95d1610) at rvalue.c:1895
#6 0x00000000004c9ace in rval_expr_eval_int (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rve=0x7fbac95d2538) at rvalue.c:2117
...
(gdb) p avp
$12 = (sr_xavp_t *) 0x7fbaae0360d0
(gdb) p *avp
$13 = {id = 2085639187, name = {s = 0x7fbaae036108 "ulattrs", len = 7}, val = {type = SR_XTYPE_XAVP, v = {i = -1375510160, s = {s = 0x7fbaae036170 "\305\345om", len = 0}, t = 140439760101744, l = 140439760101744, ll = 140439760101744,
xavp = 0x7fbaae036170, data = 0x7fbaae036170}}, next = 0x7fbaae036228}
(gdb) p *avp->next
$14 = {id = 2085639187, name = {s = 0x7fbaae036260 "ulattrs", len = 7}, val = {type = SR_XTYPE_NULL, v = {i = 0, s = {s = 0x0, len = 0}, t = 0, l = 0, ll = 0, xavp = 0x0, data = 0x0}}, next = 0x7fbaae0360d0}
(gdb) frame 0
#0 0x0000000000544235 in xavp_get_internal (name=0x7fbac95d11f8, list=0x7fbaae036248, idx=0, prv=0x0) at xavp.c:267
267 if(avp->id==id && avp->name.len==name->len
(gdb) list
262 avp = *list;
263 else
264 avp = *_xavp_list_crt;
265 while(avp)
266 {
267 if(avp->id==id && avp->name.len==name->len
268 && strncmp(avp->name.s, name->s, name->len)==0)
269 {
270 if(idx==n)
271 return avp;
(gdb)
272 n++;
273 }
274 if(prv)
275 *prv = avp;
276 avp = avp->next;
277 }
278 return NULL;
279 }
280
281 sr_xavp_t *xavp_get(str *name, sr_xavp_t *start)
I assume these linked lists should be NULL terminated (i.e. avp->next == NULL) and therefore it is a bug that my list above is a loop.
My server has got stuck because it is searching for the name of an item that is inside the nested 'ulattrs' xavp.
Can someone explain the purpose of the SR_XTYPE_NULL entry?
Can anyone else see a problem either with my patch or the xavp add/insert code that it calls? I based my patch on the code in uldb_preload_attrs(), also in udomain.c.
Regards,
Hugh
________________________________
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.
Hi,
I believe this has been discussed before but I can't find a definitive
answer.
Using kamailio 4.2 with rtpengine.
My clients don't have natively any ICE relay candidates, just host and
server reflexive from STUN.
What is the correct syntax to have rtpengine only add itself as relay
candidate with lowest priority?
The current basic kamailio config I'm testing has rtpengine_manage empty of
flags, which is almost working except that rtpengine's default behaviour in
my circumstance is to add itself as a host candidate.
Reading through
http://kamailio.org/docs/modules/devel/modules/rtpengine.html I believe
what I want (ie. rtpengine adding itself as relay candidate only with
lowest priority - not touching the rest of the SDP or any other ICE
candidates sent by the clients) is not an option. Is my interpretaion
correct or am I missing something glaringly obvious?
Thanks,
Peter
>From the module's documentation:
"The default (if no “ICE=...” is given at all), new ICE data will only
be generated if no ICE was present in the SDP originally; otherwise the RTP
proxy will only insert itself as *additional* ICE candidate."
Relevant kamailio config snippet:
route[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
rtpengine_manage("");
if (is_request()) {
if (!has_totag()) {
if(t_is_branch_route()) {
add_rr_param(";nat=yes");
}
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
if(is_first_hop())
set_contact_alias();
}
}
#!endif
return;
}
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#474 - Segfault in dialog.so
User who did this - Daniel-Constantin Mierla (miconda)
----------
If you installed at the release date or used debian packages for the release, then upgrade to latest branch 4.1 or use nightly builds for 4.1.x. There was a fix in dialog module regarding clean up of unestablished dialogs lasting too long.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=474#comment1654
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Dmitry Davletbaev (ddomgn)
Attached to Project - sip-router
Summary - Segfault in dialog.so
Task Type - Bug Report
Category - dialog
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - High
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - Operating system: Debian Wheezy 7.6
Kamailio version: 4.1.6
Unpredictable crashes of Kamailio due to segfault in dialog.so. The process can run all day
long without any crash, but the next day it can crush every hour or so. Syslog:
Oct 2 14:25:35 tel kernel: [5978975.159531] kamailio[16869]: segfault at 40
ip b6a8c0fe sp bfb598c0 error 4 in dialog.so[b6a58000+4d0 00]
Two files containing logs are attached: pid-16858.log is main Kamailio process logs and
pid-16869.log is crashed child logs. The segfault in these logs took place at
Oct 2 14:25:35.
I can provide more logs if it is necessary.
I downgraded to 4.1.5 and no segfaults occurred since then.
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=474
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.