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 <[email protected]>: > 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. <[email protected]> > 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 <[email protected]>: >> >>> 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 >>> [email protected] >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >>> >>> >> >> _______________________________________________ >> sr-dev mailing list >> [email protected] >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev >> >> > > _______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev > >
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
