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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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.
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.
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.
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?
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)
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.
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!