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,
Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com
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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
