Audacious seems to eat up memory, after a few days it occupies a few Gb of virtual memory and requires a kill -9 to be stopped. I am using the winamp like skin, and putting it under valgrind shows some error when streaming internet radios (that's the usage I am asking it to do mainly) > valgrind /usr/bin/audacious ==10533== Memcheck, a memory error detector ==10533== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==10533== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==10533== Command: /usr/bin/audacious ==10533== ==10533== Thread 4: ==10533== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==10533== at 0x72F7624: sendmmsg (in /usr/lib64/libc-2.16.so) ==10533== by 0xD2B7D8E: ??? (in /usr/lib64/libresolv-2.16.so) ==10533== by 0xD2B5484: __libc_res_nquery (in /usr/lib64/libresolv-2.16.so) ==10533== by 0xD2B6121: __libc_res_nsearch (in /usr/lib64/libresolv-2.16.so) ==10533== by 0x1A48BB41: _nss_dns_gethostbyname4_r (in /usr/lib64/libnss_dns-2.16.so) ==10533== by 0x72DD831: gaih_inet (in /usr/lib64/libc-2.16.so) ==10533== by 0x72E1470: getaddrinfo (in /usr/lib64/libc-2.16.so) ==10533== by 0x18A74ABF: ne_addr_resolve (in /usr/lib64/libneon.so.27.2.6) ==10533== by 0x18A6A15E: ??? (in /usr/lib64/libneon.so.27.2.6) ==10533== by 0x18A6A3FF: ??? (in /usr/lib64/libneon.so.27.2.6) ==10533== by 0x18A6C145: ??? (in /usr/lib64/libneon.so.27.2.6) ==10533== by 0x18A6C444: ne_begin_request (in /usr/lib64/libneon.so.27.2.6) ==10533== Address 0x13c12980 is on thread 4's stack Cheers, Chris.
After one day of valgrind: ==10533== HEAP SUMMARY: ==10533== in use at exit: 26,751,749 bytes in 183,842 blocks ==10533== total heap usage: 6,586,288 allocs, 6,402,446 frees, 1,387,637,774 bytes allocated ==10533== ==10533== LEAK SUMMARY: ==10533== definitely lost: 19,558,893 bytes in 76,368 blocks ==10533== indirectly lost: 6,208 bytes in 193 blocks ==10533== possibly lost: 1,804,433 bytes in 16,636 blocks ==10533== still reachable: 5,382,215 bytes in 90,645 blocks ==10533== suppressed: 0 bytes in 0 blocks ==10533== Rerun with --leak-check=full to see details of leaked memory ==10533==
CC: (none) => jani.valimaa, luigiwalser
CC: jani.valimaa => (none)
CC: (none) => goetz.waschk
CC: (none) => jani.valimaa
Audacious has been updated to 3.3.4 in Cauldron. Is this still valid?
Hi, unfortunately it is, here a memcheck after a few hours of 3.3.4. I'll run a full check to see if it gives more info! Cheers. ==6239== Memcheck, a memory error detector ==6239== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==6239== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6239== Command: audacious ==6239== ==6239== Thread 4: ==6239== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==6239== at 0x70F9EF4: sendmmsg (in /usr/lib64/libc-2.17.so) ==6239== by 0xD18ED4E: ??? (in /usr/lib64/libresolv-2.17.so) ==6239== by 0xD18C48F: __libc_res_nquery (in /usr/lib64/libresolv-2.17.so) ==6239== by 0xD18D0E1: __libc_res_nsearch (in /usr/lib64/libresolv-2.17.so) ==6239== by 0x1D520B71: _nss_dns_gethostbyname4_r (in /usr/lib64/libnss_dns-2.17.so) ==6239== by 0x70DF3F1: gaih_inet (in /usr/lib64/libc-2.17.so) ==6239== by 0x70E2FD0: getaddrinfo (in /usr/lib64/libc-2.17.so) ==6239== by 0x1C125ACF: ne_addr_resolve (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11B16E: ??? (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11B40F: ??? (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11D155: ??? (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11D454: ne_begin_request (in /usr/lib64/libneon.so.27.2.6) ==6239== Address 0x16a36930 is on thread 4's stack ==6239== ==6239== Thread 7: ==6239== Syscall param sendmsg(mmsg[0].msg_hdr) points to uninitialised byte(s) ==6239== at 0x70F9EF4: sendmmsg (in /usr/lib64/libc-2.17.so) ==6239== by 0xD18ED4E: ??? (in /usr/lib64/libresolv-2.17.so) ==6239== by 0xD18C48F: __libc_res_nquery (in /usr/lib64/libresolv-2.17.so) ==6239== by 0xD18D0E1: __libc_res_nsearch (in /usr/lib64/libresolv-2.17.so) ==6239== by 0x1D520B71: _nss_dns_gethostbyname4_r (in /usr/lib64/libnss_dns-2.17.so) ==6239== by 0x70DF3F1: gaih_inet (in /usr/lib64/libc-2.17.so) ==6239== by 0x70E2FD0: getaddrinfo (in /usr/lib64/libc-2.17.so) ==6239== by 0x1C125ACF: ne_addr_resolve (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11B16E: ??? (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11B40F: ??? (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11D155: ??? (in /usr/lib64/libneon.so.27.2.6) ==6239== by 0x1C11D454: ne_begin_request (in /usr/lib64/libneon.so.27.2.6) ==6239== Address 0x1bf04a10 is on thread 7's stack ==6239== ==6239== ==6239== HEAP SUMMARY: ==6239== in use at exit: 2,632,823 bytes in 22,432 blocks ==6239== total heap usage: 12,950,900 allocs, 12,928,468 frees, 3,197,778,182 bytes allocated ==6239== ==6239== LEAK SUMMARY: ==6239== definitely lost: 3,842 bytes in 105 blocks ==6239== indirectly lost: 98,704 bytes in 3,273 blocks ==6239== possibly lost: 1,430,684 bytes in 10,772 blocks ==6239== still reachable: 1,099,593 bytes in 8,282 blocks ==6239== suppressed: 0 bytes in 0 blocks
Does this only happen with the winamp-style GUI?
Just tested with the classic interface and this leaks too.
I get similar valgrind output here as well (Mageia 2, audacious 3.4-alpha1).
Is this still valid with 3.4 in current Cauldron? If so, has this been reported upstream?
Hi there, difficult to say because the winamp gui is just not functionning anymore: https://bugs.mageia.org/show_bug.cgi?id=10605 Did not reported it upstream yet, but if someone can confirm #10605 I'll do. thanks, chris.
Created attachment 4296 [details] valgrind log for audacious (one night) Hi, I ran again valgrind over audacious after #10605 is fixed. He still leaks but in a non-dramatic way 16kB to be compared to 19MB before, which makes it usuable for weeks. Moreover, I am not sure how to interpret those leaks, they seem to be in link librairies so it is not clear to me if this is a bug in audacious or linked lib. Cheers. ==32745== LEAK SUMMARY: ==32745== definitely lost: 16,440 bytes in 13 blocks ==32745== indirectly lost: 101,669 bytes in 3,443 blocks ==32745== possibly lost: 210,785 bytes in 5,653 blocks ==32745== still reachable: 1,604,760 bytes in 18,840 blocks ==32745== suppressed: 0 bytes in 0 blocks ==32745== Reachable blocks (those to which a pointer was found) are not shown. ==32745== To see them, rerun with: --leak-check=full --show-reachable=yes ==32745== ==32745== For counts of detected and suppressed errors, rerun with: -v ==32745== ERROR SUMMARY: 987 errors from 987 contexts (suppressed: 2 from 2)
Is this still valid in Cauldron?
Closing as OLD since comment #10 has got no answer in a long time (and the memory leaks are now really smaller). Please reopen if needed.
Keywords: (none) => UPSTREAMStatus: NEW => RESOLVEDResolution: (none) => OLD