Huge memory consumption with CACHE-EX

[CapNCooK]

Valgrinded version 7242 this time with;

- make DEBUG=1 OSCAM_BIN=oscam-dbg
- valgrind --leak-check=full --show-reachable=yes --error-limit=no --undef-value-errors=no --log-file=valgrind.log ./oscam-dbg -b -r0

See full debug log here: http://pastebin.com/2Mm5FrrK

==30845== 308,242,688 (294,250,112 direct, 13,992,576 indirect) bytes in 353,666 blocks are definitely lost in loss record 88 of 88
==30845==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==30845==    by 0x46B1B1: cs_malloc (oscam-simples.c:711)
==30845==    by 0x408907: cs_cache_push_to_client (oscam.c:1791)
==30845==    by 0x408CD0: cs_cache_push (oscam.c:1880)
==30845==    by 0x409761: cs_add_cache_int (oscam.c:2078)
==30845==    by 0x409B5D: cs_add_cache (oscam.c:2130)
==30845==    by 0x41D0A5: cc_cache_push_in (module-cccam.c:2110)
==30845==    by 0x41E1AB: cc_parse_msg (module-cccam.c:2345)
==30845==    by 0x4210D2: cc_recv (module-cccam.c:3056)
==30845==    by 0x410127: work_thread (oscam.c:4053)
==30845==    by 0x4E39E99: start_thread (pthread_create.c:308)
==30845== 
==30845== LEAK SUMMARY:
==30845==    definitely lost: 294,265,070 bytes in 353,703 blocks
==30845==    indirectly lost: 13,996,976 bytes in 16,833 blocks
==30845==      possibly lost: 73,296 bytes in 113 blocks
==30845==    still reachable: 1,462,771 bytes in 4,828 blocks
==30845==         suppressed: 0 bytes in 0 blocks

Thanks

[gfto]

Ok, that is something else, looking at the log right now. I have created bug report in oscam trac, it is available at : http://streamboard.de.vu:8001/ticket/2676

I also have attached simple patch that may (or may not) solve the issue. Can somebody test it?

[turbopower]

Hey Friends great news. Thank you for bug opening gfto. If you need some additional testing please notify us.

BR

[CapNCooK]

I also have attached simple patch that may (or may not) solve the issue. Can somebody test it?

Tested it, but memory is still rising..

I have a seperate cache-ex only server with about 25 peers. If you need additional info let me know.

[PlatoonRTV]

Good news is that corsair will look into it and fix it. He said that this patch is not enough.

[gfto]

Please try oscam svn rev 7243 or newer, it should contain the needed fixes to plug the leaks. Report success or no success at : http://streamboard.de.vu:8001/ticket/2676

[CapNCooK]

Tested 7245;

- memory still climbing up, but slower
- valgrinded it, log looks different:

==32677== 255,121,152 bytes in 306,636 blocks are still reachable in loss record 83 of 83==32677==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32677==    by 0x46B0FD: cs_malloc (oscam-simples.c:711)
==32677==    by 0x408928: cs_cache_push_to_client (oscam.c:1799)
==32677==    by 0x408CF1: cs_cache_push (oscam.c:1888)
==32677==    by 0x409782: cs_add_cache_int (oscam.c:2086)
==32677==    by 0x409B7E: cs_add_cache (oscam.c:2138)
==32677==    by 0x41CFF1: cc_cache_push_in (module-cccam.c:2110)
==32677==    by 0x41E0F7: cc_parse_msg (module-cccam.c:2345)
==32677==    by 0x42101E: cc_recv (module-cccam.c:3056)
==32677==    by 0x4100C7: work_thread (oscam.c:4051)
==32677==    by 0x4E39E99: start_thread (pthread_create.c:308)
==32677==
==32677== LEAK SUMMARY:
==32677==    definitely lost: 8,574 bytes in 29 blocks
==32677==    indirectly lost: 240 bytes in 10 blocks
==32677==      possibly lost: 6,256 bytes in 23 blocks
==32677==    still reachable: 283,402,904 bytes in 970,611 blocks
==32677==         suppressed: 0 bytes in 0 blocks
==32677==
==32677== For counts of detected and suppressed errors, rerun with: -v
==32677== ERROR SUMMARY: 9 errors from 9 contexts (suppressed: 0 from 0)

reported and updated ticket.

[gfto]

So bug stays, it is still not fixed unfortunately :(

[wimpie007]

indeed.
Running into the same problem. reverting to older version because of this.
Mem slowly fills up, suddenly rises very quick until death...
very annoying...

[CapNCooK]

I'm not that familiar with tickets and priorities in the Oscam trac, but it seems to me that this is a major bug for cache-ex users..
Hopefully this problem will be prioritized by the devs accordingly, and fixed soon...

For now i'm still stuck at 7190.