Resent after signing up, due to original message being held for review for a week:
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, though that is just with 1 param.
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 (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio: 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 even 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
Hi, Could you please tell me the chunk of code that illustrates this problem? Thanks!
2014-07-16 14:10 GMT+04:00 Örn Arnarson orn@arnarson.net:
Resent after signing up, due to original message being held for review for a week:
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, though that is just with 1 param.
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 (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio: 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 even 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
If you mean the python code, then here's an example:
divheader = "Diversion: sip:%s@%s;reason=unconditional\r\n" % (1234567, "10.11.12.13") msg.call_function("insert_hf", divheader, "Diversion")
Regards, Örn
On Wed, Jul 16, 2014 at 10:32 AM, Konstantin M. evilzluk@gmail.com wrote:
Hi, Could you please tell me the chunk of code that illustrates this problem? Thanks!
2014-07-16 14:10 GMT+04:00 Örn Arnarson orn@arnarson.net:
Resent after signing up, due to original message being held for review for a week:
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, though that is just with 1 param.
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 (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio: 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 even 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
That's weird, because I'm using exactly the same way of phone number substitution and this works to me. Ok, I'll investigate this problem as soon as possible. Thanks for report!
2014-07-16 14:39 GMT+04:00 Örn Arnarson orn@arnarson.net:
If you mean the python code, then here's an example:
divheader = "Diversion: sip:%s@%s;reason=unconditional\r\n" % (1234567, "10.11.12.13") msg.call_function("insert_hf", divheader, "Diversion")
Regards, Örn
On Wed, Jul 16, 2014 at 10:32 AM, Konstantin M. evilzluk@gmail.com wrote:
Hi, Could you please tell me the chunk of code that illustrates this problem? Thanks!
2014-07-16 14:10 GMT+04:00 Örn Arnarson orn@arnarson.net:
Resent after signing up, due to original message being held for review for a week:
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, though that is just with 1 param.
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 (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio: 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 even 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Thanks. Let me know if I can assist you in any way.
On Wed, Jul 16, 2014 at 11:29 AM, Konstantin M. evilzluk@gmail.com wrote:
That's weird, because I'm using exactly the same way of phone number substitution and this works to me. Ok, I'll investigate this problem as soon as possible. Thanks for report!
2014-07-16 14:39 GMT+04:00 Örn Arnarson orn@arnarson.net:
If you mean the python code, then here's an example:
divheader = "Diversion: sip:%s@%s;reason=unconditional\r\n" % (1234567, "10.11.12.13") msg.call_function("insert_hf", divheader, "Diversion")
Regards, Örn
On Wed, Jul 16, 2014 at 10:32 AM, Konstantin M. evilzluk@gmail.com wrote:
Hi, Could you please tell me the chunk of code that illustrates this problem? Thanks!
2014-07-16 14:10 GMT+04:00 Örn Arnarson orn@arnarson.net:
Resent after signing up, due to original message being held for review for a week:
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, though that is just with 1 param.
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 (debugging by returning early), and it seems to be the fixup part, which as far as I can tell has something to do with string formatting for kamailio: 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 even 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Konstantin M. -
Örn Arnarson