[OpenSIPS-Users] Leak AVPOS + SQLITE

[Răzvan Crainea]

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
> 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/23bdbebd/attachment.htm>