[OpenSIPS-Users] Leak AVPOS + SQLITE

Rodrigo Pimenta Carvalho pimenta at inatel.br
Wed Jun 22 14:16:40 CEST 2016


Ok.


Thank you very much!


Regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979


________________________________
De: users-bounces at lists.opensips.org <users-bounces at lists.opensips.org> em nome de Razvan Crainea <razvan at opensips.org>
Enviado: quarta-feira, 22 de junho de 2016 04:04
Para: users at lists.opensips.org
Assunto: Re: [OpenSIPS-Users] Leak AVPOS + SQLITE


Hi, Rodrigo!


Valgrind may report some memory allocated, and not freed, but that is not necessarily a memory leak. There is a single block of 1024 bytes not freed during runtime, so I think that is peanuts. The memory used by OpenSIPS is not allocated with malloc, so cannot be traced by valgrind.

Regarding the system memory, it is normal to decrease as OpenSIPS uses that memory during runtime. However, after some time, this should  stabilize. Anyhow, sometimes the system memory might generate false alarms, so if you are tracing any memory leaks, you should check OpenSIPS's internal statistics.


Best regards,

Razvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com<http://www.opensips-solutions.com>

Home - OpenSIPS Solutions<http://www.opensips-solutions.com/>
www.opensips-solutions.com
OpenSIPS is a mature Open Source implementation of a SIP server. OpenSIPS is more than a SIP proxy/router as it includes application-level functionalities.

On 06/21/2016 10:38 PM, Rodrigo Pimenta Carvalho wrote:

Hi.


Does someone here is getting/handling memory leaks with OpenSIPS 2.2 and last version of SQLite?

I'm using newest commit from OpenSIPS 2.2 and newest version of SQLite.


My query is :


avp_db_query("select Value from GeneralConfigurations where Attribute = 'CONFIGURATION_INTERCOM_A_NAME'");


Valgrind shows:


==16087== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)

==16088== Searching for pointers to 296,489 not-freed blocks

==16088== Checked 103,297,688 bytes

==16088==

==16088== 1,024 bytes in 1 blocks are possibly lost in loss record 184 of 246

==16088==    at 0x4C2745D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)

==16088==    by 0x8F8B05F: sqlite3MemMalloc (sqlite3.c:20167)

==16088==    by 0x8F701C7: sqlite3Malloc (sqlite3.c:23846)

==16088==    by 0x8F75459: pcache1Alloc (sqlite3.c:44312)

==16088==    by 0x8F8019F: sqlite3BtreeCursor (sqlite3.c:44455)

==16088==    by 0x8FD0FDD: sqlite3VdbeExec (sqlite3.c:80098)

==16088==    by 0x8FDB89F: sqlite3_step (sqlite3.c:75131)

==16088==    by 0x8FDC9A1: sqlite3_exec (sqlite3.c:108122)

==16088==    by 0x8D20736: db_sqlite_raw_query (dbase.c:358)

==16088==    by 0x9464DB8: db_query_avp (avpops_db.c:436)

==16088==    by 0x946943E: ops_dbquery_avps (avpops_impl.c:840)

==16088==    by 0x9459A61: w_dbquery_avps (avpops.c:1395)

==16088==

==16088== LEAK SUMMARY:

==16088==    definitely lost: 0 bytes in 0 blocks

==16088==    indirectly lost: 0 bytes in 0 blocks

==16088==      possibly lost: 1,024 bytes in 1 blocks

==16088==    still reachable: 47,457,573 bytes in 296,488 blocks

==16088==         suppressed: 0 bytes in 0 blocks

==16088== Reachable blocks (those to which a pointer was found) are not shown.

==16088== To see them, rerun with: --leak-check=full --show-leak-kinds=all



After some time running that query, I can see, via command top, that the available memory is decreasing.

In fact, the memory is not freed even after stop running the query for a time.


Best regards.


RODRIGO PIMENTA CARVALHO
Inatel Competence Center
Software
Ph: +55 35 3471 9200 RAMAL 979








_______________________________________________
Users mailing list
Users at lists.opensips.org<mailto:Users at lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160622/7c18faeb/attachment.htm>


More information about the Users mailing list