[OpenSIPS-Devel] [OpenSIPS/opensips] Fix a crash in the python module. (#1050)

Răzvan Crainea razvan at opensips.org
Wed Feb 15 03:50:47 EST 2017


Hi, Maxim!

At this point, I think an extra strdup() is the best way to go.
Later on, when we will decide to migrate to Python >3.4, we will be able 
to provide our own heap allocators[1]. I think this is the way we should 
aim.
We are already planning some refactoring of this in the OpenSIPS 3.x 
branch. Most likely this is something that we should consider when doing 
devel there.

Regarding the Pull request you've done, I will send some comments on github.

[1] 
https://www.python.org/dev/peps/pep-0445/#make-pymem-malloc-reuse-pymem-rawmalloc-by-default

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 02/15/2017 04:21 AM, Maxim Sobolev wrote:
> Opted out to do extra strdup() at this point. Still, would be nice to 
> have fixup API to be more flexible with the arguments management. In 
> my view this would greatly enhance ability to hook opensips into 
> high-performance language and other backends, which are likely to have 
> its own heap management.
>
> https://github.com/OpenSIPS/opensips/pull/1056
>
> On Mon, Feb 13, 2017 at 9:06 PM, Maxim Sobolev <sobomax at sippysoft.com 
> <mailto:sobomax at sippysoft.com>> wrote:
>
>     Hi Bogdan, thanks for merging this little fix. It turns out there
>     is another mode of failure in this module now. This is in the case
>     when we pass a string argument that is getting converting to uint
>     via fixup_spve_uint(). The string is allocated by the python code,
>     so it fails when fixup_uint() is trying to deallocate it. One
>     obvious way to fix this would be to pkg_malloc() and copy, but
>     that's obviously an unnecessary overhead. I was curious what do
>     you guys think about extending "fixup" API to take some additional
>     flags to avoid trying to pkg_free() any of the parameters?
>     Obviously that would touch many modules, so it would be nice to
>     make the API generic and so that more options can be added in the
>     future. I made some proof of concept patch over this weekend,
>     would be nice to hear some feedback on general approach:
>
>     https://github.com/OpenSIPS/opensips/compare/master...sippy:master_fixup_opts
>     <https://github.com/OpenSIPS/opensips/compare/master...sippy:master_fixup_opts>
>
>     Some debug wrt crash in question is below:
>
>     msg.call_function('www_challenge', realm, '0')
>
>     It tries to deallocate "0" that is managed by the python code.
>
>     (gdb) print act->elem[2]
>     $4 = {type = 1, u = {number = 34368845180, string = 0x8008af57c
>     "0", data = 0x8008af57c, s = {s = 0x8008af57c "0", len = 0}, item
>     = 0x8008af57c}}
>
>
>     #1  0x0000000800c7f386 in raise () from /lib/libc.so.7
>     #2  0x0000000800c7f309 in abort () from /lib/libc.so.7
>     #3  0x00000000004706fc in fixup_uint ()
>     #4  0x0000000000473baa in fixup_spve_uint ()
>     #5  0x0000000803bc5473 in msg_call_function (self=0x800822198,
>     args=0x80aaf38c0) at python_msgobj.c:240
>     #6  0x0000000803eb5393 in PyEval_EvalFrameEx () from
>     /usr/local/lib/libpython2.7.so.1
>     #7  0x0000000803eae2c4 in PyEval_EvalCodeEx () from
>     /usr/local/lib/libpython2.7.so.1
>     #8  0x0000000803e3e74c in ?? () from /usr/local/lib/libpython2.7.so.1
>     #9  0x0000000803e1a854 in PyObject_Call () from
>     /usr/local/lib/libpython2.7.so.1
>     #10 0x0000000803e26913 in ?? () from /usr/local/lib/libpython2.7.so.1
>     #11 0x0000000803e1a854 in PyObject_Call () from
>     /usr/local/lib/libpython2.7.so.1
>     #12 0x0000000803eb9efd in PyEval_CallObjectWithKeywords () from
>     /usr/local/lib/libpython2.7.so.1
>     #13 0x0000000803bc7ace in python_exec2 (_msg=0x801428b80,
>     method_name=0x801425d88 "www_authenticate", mystr=0x0) at
>     python_exec.c:100
>     #14 0x0000000803bc7633 in python_exec1 (_msg=0x801428b80,
>     method_name=0x801425d88 "www_authenticate", foobar=0x0) at
>     python_exec.c:41
>
>     -Max
>
>
>
>     On Mon, Feb 13, 2017 at 12:27 AM, Bogdan Andrei IANCU
>     <notifications at github.com <mailto:notifications at github.com>> wrote:
>
>         Merged #1050 <https://github.com/OpenSIPS/opensips/pull/1050>.
>
>>         You are receiving this because you authored the thread.
>         Reply to this email directly, view it on GitHub
>         <https://github.com/OpenSIPS/opensips/pull/1050#event-959176889>,
>         or mute the thread
>         <https://github.com/notifications/unsubscribe-auth/AANWJtg_7ZwxY2Vhvx4XhfifG-MWtQOEks5rcBPogaJpZM4L-Ki_>.
>
>
>
>
>
> -- 
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sales at sippysoft.com <mailto:sales at sippysoft.com>
> Skype: SippySoft
>
>
> _______________________________________________
> Devel mailing list
> Devel at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20170215/42b0f95d/attachment-0001.html>


More information about the Devel mailing list