Possible memory leak in minidlna?

Help
Anonymous
2011-08-05
2013-05-29
  • Anonymous - 2011-08-05

    I installed minidlna 1.0.21-1 on an Arch Linux ARM distribution (Pogoplug). It works great! However I found its memory usage increases over time. For example, it started by using 39MB virtual memory and 9MB resident memory. It then constantly using more memory, in the rate at around 2.5MB per hour. For example, after 8 hours, the memory usage increased to 60MB virtual and 29MB resident. It is not the media scanning, because the memory usage never stopped increasing. Since my Pogoplug box is tight on memory, it is sensitive to this kind of memory leak. So I wonder if this is a known issue and if there is any workaround. Thanks

     
  • Justin Maggard

    Justin Maggard - 2011-08-05

    I haven't been able to find any memory leaks with valgrind.  However, if minidlna is in use, the sqlite3 database cache can grow fairly large.  You can tune this by reducing the default_cache_size setting in minidlna.c's open_db() function.

     
  • Anonymous - 2011-08-07

    Thanks for replying. However, I doubt it is the problem. First, the memory use increase even when minidlna is idle. Second, I removed all the media directories from the configuration, removed cached database and started minidlna again. The minidlna process still increases memory use at the same rate. This is really intriguing. I will try to use a normal Linux distribution and see if it has the same issue.

     
  • Anonymous - 2011-08-07

    I tried to run minidlna on an Ubuntu 10.04 system. It demonstrated the same behavior. memory use increase once every 5 minutes, by around 200KB.

    The minidlna was the binary I just downloaded from source forge. I didn't give it any media file. So basically it was running with an empty database. Then I just used "top -p <pid>" to see the memory use grow.

     
  • Justin Maggard

    Justin Maggard - 2011-08-08

    Here's what happens on my system running for the last 20 minutes:

    $ while true; do ps u -p 13765 u; sleep 300; done
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    jmaggard 13765  0.0  0.1  36268  5348 ?        Ssl  14:20   0:00 ./minidlna
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    jmaggard 13765  0.0  0.1  36268  5348 ?        Ssl  14:20   0:00 ./minidlna
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    jmaggard 13765  0.0  0.1  36268  5348 ?        Ssl  14:20   0:00 ./minidlna
    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    jmaggard 13765  0.0  0.1  36268  5348 ?        Ssl  14:20   0:00 ./minidlna

    No memory use increase whatsoever.  So I have no idea what you're seeing.  Maybe you can compile an unstripped binary and run it through valgrind?

     
  • Anonymous - 2011-08-10

    I compile the source code downloaded from SourceForge and used valgrind. The memory usage still increases over time. Valgrind generated the following report when I used "kill <pid>" to end minidlna after about 20 minutes:

    ==5472== HEAP SUMMARY:
    ==5472==     in use at exit: 852,480 bytes in 1,440 blocks
    ==5472==   total heap usage: 2,304 allocs, 864 frees, 1,193,750 bytes allocated
    ==5472==
    ==5472== 852,480 (28,416 direct, 824,064 indirect) bytes in 48 blocks are definitely lost in loss record 2 of 2
    ==5472==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
    ==5472==    by 0x40FD5C: NameValueParserStartElt (upnpreplyparse.c:50)
    ==5472==    by 0x410007: parseelt (minixml.c:135)
    ==5472==    by 0x410123: parsexml (minixml.c:188)
    ==5472==    by 0x40FBF7: ParseNameValue (upnpreplyparse.c:87)
    ==5472==    by 0x41180A: ParseUPnPClient (minissdp.c:444)
    ==5472==    by 0x411E5D: ProcessSSDPRequest (minissdp.c:576)
    ==5472==    by 0x4075C9: main (minidlna.c:1148)
    ==5472==
    ==5472== LEAK SUMMARY:
    ==5472==    definitely lost: 28,416 bytes in 48 blocks
    ==5472==    indirectly lost: 824,064 bytes in 1,392 blocks
    ==5472==      possibly lost: 0 bytes in 0 blocks
    ==5472==    still reachable: 0 bytes in 0 blocks
    ==5472==         suppressed: 0 bytes in 0 blocks
    ==5472==
    ==5472== For counts of detected and suppressed errors, rerun with: -v
    ==5472== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)

     
  • Justin Maggard

    Justin Maggard - 2011-08-10

    Ah, great, that points right to it!  I just checked in a fix into CVS.  Can you please verify it?

    I wasn't able to see the leak because only a couple different clients will ever follow that code path, and I don't have any of them.

     
  • Anonymous - 2011-08-10

    Thanks for the quick turnaround. I've verified you code changes works (both with and without valgrind) and the memory leak is gone. I can't wait for the next release (because I would need an ARM build…)

    Minidlna is the best among all DLNA/uPnp servers I've tried, especially for a small plug computer like a pogoplug. Thank you for all the hard work!

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks