search

khenriks / mp3fs

FUSE-based transcoding filesystem from FLAC to MP3
http://khenriks.github.io/mp3fs/
GNU General Public License v3.0
382 stars 46 forks source link

Invert test for null id3_tag before deletion, fixing memory leak. #39

Closed patch0 closed 9 years ago

patch0 commented 9 years ago

Hi there,

I found mp3fs eating all my ram. A quick pass through valgrind revealed that the id3 tag wasn't being freed properly. I ran valgrind as

valgrind --tool=memcheck --trace-children=no --leak-check=full  ./mp3fs -b 192 /home/music/music/ /mnt/music -o allow_other,ro,debug

and then ran a simple ls -la /mnt/music/WhiskyCats/WhiskyCats.


==13478== HEAP SUMMARY:
==13478==     in use at exit: 22,680 bytes in 353 blocks
==13478==   total heap usage: 4,860 allocs, 4,507 frees, 67,409,660 bytes allocated
==13478== 
==13478== 232 (48 direct, 184 indirect) bytes in 1 blocks are definitely lost in loss record 8 of 19
==13478==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13478==    by 0x54C85AA: id3_tag_new (in /usr/lib/libid3tag.so.0.3.0)
==13478==    by 0x40AF6F: Mp3Encoder::Mp3Encoder() (mp3_encoder.cc:66)
==13478==    by 0x406068: Encoder::CreateEncoder(std::string) (coders.cc:39)
==13478==    by 0x406160: check_encoder (coders.cc:75)
==13478==    by 0x404E86: main (mp3fs.c:185)
==13478== 
==13478== 22,448 (576 direct, 21,872 indirect) bytes in 12 blocks are definitely lost in loss record 19 of 19
==13478==    at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==13478==    by 0x54C85AA: id3_tag_new (in /usr/lib/libid3tag.so.0.3.0)
==13478==    by 0x40AF6F: Mp3Encoder::Mp3Encoder() (mp3_encoder.cc:66)
==13478==    by 0x406068: Encoder::CreateEncoder(std::string) (coders.cc:39)
==13478==    by 0x40592F: transcoder_new (transcode.cc:52)
==13478==    by 0x405884: mp3fs_getattr (fuseops.c:210)
==13478==    by 0x4E416A7: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.2)
==13478==    by 0x4E418DC: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.2)
==13478==    by 0x4E4C25A: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.2)
==13478==    by 0x4E48E78: ??? (in /lib/x86_64-linux-gnu/libfuse.so.2.9.2)
==13478==    by 0x618A181: start_thread (pthread_create.c:312)
==13478==    by 0x649AEFC: clone (clone.S:111)
==13478== 
==13478== LEAK SUMMARY:
==13478==    definitely lost: 624 bytes in 13 blocks
==13478==    indirectly lost: 22,056 bytes in 340 blocks
==13478==      possibly lost: 0 bytes in 0 blocks
==13478==    still reachable: 0 bytes in 0 blocks
==13478==         suppressed: 0 bytes in 0 blocks
==13478== 
==13478== For counts of detected and suppressed errors, rerun with: -v
==13478== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

With this patch no leak is reported:


==13768== HEAP SUMMARY:
==13768==     in use at exit: 0 bytes in 0 blocks
==13768==   total heap usage: 4,860 allocs, 4,860 frees, 67,409,660
bytes allocated
==13768== 
==13768== All heap blocks were freed -- no leaks are possible
==13768== 
==13768== For counts of detected and suppressed errors, rerun with: -v
==13768== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
khenriks commented 9 years ago

Thanks very much for the contribution. Sorry it's taken so long for my response.