Kamailio terminates (Signal 15) after app_python crashes (signal 7) when
using call_function("append_hf") with more than 1 parameter.
Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: ALERT: <core> [main.c:788]:
handle_sigs(): child process 2707 exited by a signal 7
Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: ALERT: <core> [main.c:791]:
handle_sigs(): core was generated
Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2699]: INFO: <core> [main.c:803]:
handle_sigs(): INFO: terminating due to SIGCHLD
Jul 9 13:53:18 vcr01 /usr/sbin/kamailio[2706]: INFO: <core> [main.c:854]:
sig_usr(): INFO: signal 15 received
Actually, calling "remove_hf" with call_function seems to do exactly the
same thing.
My problem is that I need to manipulate the Diversion headers (or rather,
add a new Diversion header in the correct place (i.e. above the other
Diversion header), as append_hf will always add it at the bottom.)
I've identified what part of the code makes it crash by returning early,
but it seems to be the fixup part:
if (fexport->fixup != NULL) {
if (i >= 3) {
rval = fexport->fixup(&(act->val[3].u.data), 2);
if (rval < 0) {
PyErr_SetString(PyExc_RuntimeError, "Error in fixup (2)");
Py_INCREF(Py_None);
return Py_None;
}
act->val[3].type = MODFIXUP_ST;
}
if (i >= 2) {
rval = fexport->fixup(&(act->val[2].u.data), 1);
if (rval < 0) {
PyErr_SetString(PyExc_RuntimeError, "Error in fixup (1)");
Py_INCREF(Py_None);
return Py_None;
}
act->val[2].type = MODFIXUP_ST;
}
if (i == 1) {
rval = fexport->fixup(0, 0);
if (rval < 0) {
PyErr_SetString(PyExc_RuntimeError, "Error in fixup (0)");
Py_INCREF(Py_None);
return Py_None;
}
}
}
I have very little experience with programming in C, and much less
debugging with gdb or something similar, but from comparing this code with
the way the Perl module does this, I couldn't see any obvious problems. I'm
hoping someone with familiarity with the kamailio functions, such as fixup,
might be able to identify the problem.
Judging from the exit code of app_python, my (uninformed) guess would be
that there's an attempt to access or manipulate something in an
out-of-scope memory address.
Any suggestions would be greatly appreciated. I've written a quite large
routing function in python and I'd like to avoid rewriting it in a
different scripting language if possible.
The kamailio version I'm running is 4.0.4
Regards,
Örn
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#448 - usrloc driver error on query: Duplicate entry 'XXXXXXXXXXXX' for key 'ruid_idx'
User who did this - Savolainen Dmitri (sdi)
----------
something more about commit 66c497fdf4ac1c3b889a7c3b50c3e5fed770cf0b
It works, excluding one moment (at least)
1. cseq=1 (in DB)
2. reboot kamailio
atfter reboot "kamctl ul add" will start incrementing from cseq=1 for permanent registration so DB update and insert failed. But it is better than nothing. Are you going commit this patch for 4.1.x?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=448#comment1539
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.
We don't want to use ICE. Is there any way to stop rtpengine from adding
this to the SDP body?
a=ice-ufrag:5eI4YS1M
a=ice-pwd:xHGuc5ksYWxv19jTcVpxBeIEqqJm
a=candidate:0aynDMzbnaYfD3dW 1 UDP 2130706432 xxx.xxx.xxx.xxx 31318 typ
host
a=candidate:0aynDMzbnaYfD3dW 2 UDP 2130706431 xxx.xxx.xxx.xxx 31319 typ host
It unnecessarily bloats the SDP body and causes problems.
--
Alex Balashov - Principal
Evariste Systems LLC
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
Please be kind to the English language:
http://www.entrepreneur.com/article/232906
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#440 - CRASH: segmentation fault if there is no dispatcher available
User who did this - Nuno Miguel Reis (nmreis)
----------
Hi Daniel.
I noticed now that i'm getting: tm [tm.c:1518]: _w_t_relay_to(): ERROR: w_t_relay_to: unsupported route type: 64 a lot
By looking at source code i see that there is now handling for route type: LOCAL_ROUTE in _w_t_relay_to(...). Shouldn't we add something here at least to avoid the constant loggging?
Looking forward to here from you.
Nuno.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=440#comment1532
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 - Nuno Miguel Reis (nmreis)
Attached to Project - sip-router
Summary - CRASH: Program terminated with signal 6, Aborted.
Task Type - Bug Report
Category - dialog
Status - Unconfirmed
Assigned To -
Operating System - Linux
Severity - Critical
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - Hello all.
I've just had another segmentation fault issue in kamailio on a production scenario with an uptime of about 2 days.
Please find attached the full backtrace for more hints.
Please let me know if anything else is needed.
This happened on 4.1.4, git: 2198cb5d508055f495af29866045d51c1098d5cc + cherry pick of git commit: 4fab97fb54334a55b1fce4e0d2f417fda5727c3a.
Thanks.
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=449
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.
Hi!
These modules seems to depend a bit on a Linux system, reading /proc data, but it's not documented. Should we add this to the docs? Does the module work on *BSD systems at all?
The database support in pipelimit seems like a good idea, but there's no reload RPC command. Is there a reason for this? WIll it not work if we implement it?
I would like to be able to change the pipes during runtime.
/O
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#448 - usrloc driver error on query: Duplicate entry 'XXXXXXXXXXXX' for key 'ruid_idx'
User who did this - Savolainen Dmitri (snen)
----------
commit 66c497fdf4ac1c3b889a7c3b50c3e5fed770cf0b doesn't resolve this
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=448#comment1538
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.
The following task has a new comment added:
FS#448 - usrloc driver error on query: Duplicate entry 'XXXXXXXXXXXX' for key 'ruid_idx'
User who did this - Savolainen Dmitri (snen)
----------
Yes, it is about adding the same record twice, but it doesn't matter via kamctl or via sip-endpoint. Just kamctl with permanent registration is more clearly, because there is no expire. Same update with expire will try to INSERT until expired (or adding not same record)
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=448#comment1537
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.
The following task has a new comment added:
FS#445 - modules/tmx: t_is_failure_route() code or documentation is wrong
User who did this - Daniel-Constantin Mierla (miconda)
----------
That is correct to get false from t_is_failure_route() if executed from a route block called from branch_route.
t_is_failure_route() returns true in a route block that was executed from failure_route.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=445#comment1536
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.
The following task has a new comment added:
FS#448 - usrloc driver error on query: Duplicate entry 'XXXXXXXXXXXX' for key 'ruid_idx'
User who did this - Daniel-Constantin Mierla (miconda)
----------
To be sure it is clear what you did -- it is about adding the same record twice (same aor and same contact uri), right?
I pushed a patch in master branch to generate callid randomly at startup and then increase cseq for each new add command.
Can you test and see if fixes your use case? The commit is:
- http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=66c497f…
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=448#comment1535
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.