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:
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(a)gmail.com <mailto:miconda@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-cen…
<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(a)gmail.com <mailto:jurijs.ivolga@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(a)gmail.com <mailto:miconda@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(a)gmail.com <mailto:miconda@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.linkedin.com/in/miconda>
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -