[SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

Olle E. Johansson oej at edvina.net
Mon Nov 7 10:44:16 CET 2016


I think we need to update the Make system instead of the docs to avoid this version.
Or implement some code like we have for OpenSSL that outputs warnings at runtime.

/O
> On 07 Nov 2016, at 10:42, Jurijs Ivolga <jurijs.ivolga at gmail.com> wrote:
> 
> Hi Daniel,
> 
> I found modules what are impacted by this leak:
> 
> http_client
> utils
> xcap
> http_async_client
> auth_identity
> xcap_client
> 
> I would like to update documentations, but this is first time when I'm updating documentation.
> 
> I believe I need to update xml file for module. Should I then regenerate readme file as stated here:
> 
> https://www.kamailio.org/wiki/devel/how-to/module-readme <https://www.kamailio.org/wiki/devel/how-to/module-readme>
> 
> Or not?
> 
> Then I believe to create pull request with my changes. Correct?
> 
> Maybe you have manual for this?
> 
> With kind regards,
> 
> Jurijs
> 
> On Wed, Oct 12, 2016 at 4:30 PM, Daniel-Constantin Mierla <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
> Hello,
> 
> ok, so that was...
> 
> Maybe it would be good to add a note to the docs of the module about this issue so people become aware of it. I guess the other http_* modules are affected. Pull requests or other suggestions are welcome, of course!
> 
> Cheers,
> Daniel
> 
> On 12/10/16 15:04, Jurijs Ivolga wrote:
>> Hi Daniel,
>> 
>> Thank you a lot, it looks that issue is solved, after updating libcurl.
>> 
>> I was using following manual for updating libcurl, in case if somebody will have same issue.
>> 
>> https://www.digitalocean.com/community/questions/how-to-upgrade-curl-in-centos6 <https://www.digitalocean.com/community/questions/how-to-upgrade-curl-in-centos6>
>> 
>> With kind regards,
>> 
>> Jurijs
>> 
>> On Tue, Oct 11, 2016 at 2:43 PM, Jurijs Ivolga <jurijs.ivolga at gmail.com <mailto:jurijs.ivolga at gmail.com>> wrote:
>> Hi Daniel,
>> 
>> You are correct we are using heavily http_query.
>> 
>> I found following bug report:
>> 
>> https://bugs.centos.org/view.php?id=9391 <https://bugs.centos.org/view.php?id=9391>
>> 
>> I will try to update to libcurl 7.44 and check if this help.
>> 
>> Thank you a lot Daniel!
>> 
>> With kind regards,
>> 
>> Jurijs
>> 
>> On Tue, Oct 11, 2016 at 10:55 AM, Daniel-Constantin Mierla <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>> Hello,
>> 
>> from the logs, it seems to be related to curl library, I see many reports like:
>> 
>> ==16459== 189,318 bytes in 167 blocks are possibly lost in loss record 681 of 683
>> ==16459==    at 0x4C26FEF: calloc (vg_replace_malloc.c:711)
>> ==16459==    by 0x104BB699: ??? (in /usr/lib64/libnsspem.so)
>> ==16459==    by 0x104AA537: ??? (in /usr/lib64/libnsspem.so)
>> ==16459==    by 0x104AB81E: ??? (in /usr/lib64/libnsspem.so)
>> ==16459==    by 0x104B0B88: ??? (in /usr/lib64/libnsspem.so)
>> ==16459==    by 0x104B77E1: ??? (in /usr/lib64/libnsspem.so)
>> ==16459==    by 0xB71ABC9: ??? (in /usr/lib64/libnss3.so)
>> ==16459==    by 0xB71AE62: PK11_CreateGenericObject (in /usr/lib64/libnss3.so)
>> ==16459==    by 0xA0674DF: ??? (in /usr/lib64/libcurl.so.4.1.1)
>> ==16459==    by 0xA067666: ??? (in /usr/lib64/libcurl.so.4.1.1)
>> ==16459==    by 0xA069141: ??? (in /usr/lib64/libcurl.so.4.1.1)
>> ==16459==    by 0xA0601C4: Curl_ssl_connect (in /usr/lib64/libcurl.so.4.1.1)
>> That's like almost 200KB lost in this report.
>> From the list of the modules, I see you have utils and I guess you use http query function from there, is it?
>> 
>> Cheers,
>> Daniel
>> 
>> On 10/10/16 12:06, Jurijs Ivolga wrote:
>>> Hi Daniel,
>>> 
>>> I left valgrind running for little while, not sure if this will be enough.
>>> 
>>> Please find attached log file.
>>> 
>>> Thank you a lot for your help!
>>> 
>>> With kind regards,
>>> 
>>> Jurijs
>>> 
>>> On Fri, Oct 7, 2016 at 7:15 PM, Daniel-Constantin Mierla <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>>> Hello,
>>> 
>>> that's the way it was done for older versions of kamailio.
>>> 
>>> In master and 4.4 the memory debugging is turned on and it is reflected by the presence of DBG_SR_MEMORY in the output of 'kamailio -v'.
>>> 
>>> Anyhow, what you reported is not a leak inside kamailio memory manager, but a leak of using system memory, so it is not affected by DBG_SR_MEMORY and cannot be troubleshooted using the mechanisms for pkg and shm managers.
>>> 
>>> Cheers,
>>> Daniel
>>> 
>> 
>> -- 
>> Daniel-Constantin Mierla
>> http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> - http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
>> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com <http://www.asipto.com/>-- 
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda <http://twitter.com/#!/miconda> - http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com <http://www.asipto.com/>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161107/2d3d94f9/attachment.html>


More information about the sr-users mailing list