I'm using GDBus (via Glib) and I have code like:
method_call_message = g_dbus_message_new_method_call(owner,
OBJECT_PATH,
INTERFACE_NAME,
"get_snmpv2_mib");
GVariant *gv = g_variant_new("(sissi)", ip, port, mib, variable, instance);
g_dbus_message_set_body(method_call_message, gv);
I assume method_call_message is now a container for gv.
Before exiting I call:
g_object_unref(method_call_message);
I assume this will then schedule BOTH method_call_message and gv for GC?
When is GC done?
I appear to be leaking some 4 bytes at a time as I watch the top updates on VIRT memory.
I have commented out pieces of code till I localized it (the leak) to my GDBus calls.
Using some Valgrind magic:
libtool exec valgrind --tool=memcheck --leak-check=full --log-file=w <executable + args>
I was able to winnow out the memory management obfuscation and get to a call-stack that showed the problem. The Valgrind output indicated that all my memory losses were associated with calls to g_variant_get(...):
at 0x4A06A2E: malloc (vg_replace_malloc.c:270)
==20088== by 0x3F21E503B6: g_malloc (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E6860D: g_strdup (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E7FD01: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E7FA61: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E80348: g_variant_get_va (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E80585: g_variant_get (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x4C30555: server_gvariant (in /usr/lib64/libdrsnvc.so)
==20088== by 0x40257B: NVCtimerCB(void*) (main.cc:73)
==20088== by 0x3F21E48C3A: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E48519: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.4400.1)
==20088== by 0x3F21E4A5A7: ??? (in /usr/lib64/libglib-2.0.so.0.4400.1)
Obviously the call to g_variant_get(...) begats a call to g_strdup(...) (if your format_string includes an 's' for string). So, in my case, the code is:
g_variant_get(response, "(isi)", &od.stat, &od.msg, &od.i);
gchar *tmp = od.msg;
od.msg = strncpy(msg, od.msg, strlen(od.msg)); /* copy string */
g_free(tmp); /* free g_strdup allocated space */
And a call to g_free(...) frees the allocated storage.
Now I get:
LEAK SUMMARY:
==6472== definitely lost: 0 bytes in 0 blocks
==6472== indirectly lost: 0 bytes in 0 blocks
==6472== possibly lost: 9,841 bytes in 148 blocks
==6472== still reachable: 106,376 bytes in 986 blocks
==6472== suppressed: 0 bytes in 0 blocks
Related
I am learning pthreads programming.
I understood that there are two states of thread:
1. Joinable
2. Detachable
In case of Joinable, we need to call pthread_join to free the resources(stack), whereas in case of detached there is no need to call pthread_join and the resources will be freed on thread exit.
I wrote a sample program to observe the behavior
#include <stdio.h>
#include <pthread.h>
#include <stdlib.h>
void *threadFn(void *arg)
{
pthread_detach(pthread_self());
sleep(1);
printf("Thread Fn\n");
pthread_exit(NULL);
}
int main(int argc, char *argv[])
{
pthread_t tid;
int ret = pthread_create(&tid, NULL, threadFn, NULL);
if (ret != 0) {
perror("Thread Creation Error\n");
exit(1);
}
printf("After thread created in Main\n");
pthread_exit(NULL);
}
When i try to check any mem leaks with valgrind it gave me leaks of 272 bytes. Can you show me why is the leak happening here.
$valgrind --leak-check=full ./app
==38649==
==38649== HEAP SUMMARY:
==38649== in use at exit: 272 bytes in 1 blocks
==38649== total heap usage: 7 allocs, 6 frees, 2,990 bytes allocated
==38649==
==38649== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==38649== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==38649== by 0x40134A6: allocate_dtv (dl-tls.c:286)
==38649== by 0x40134A6: _dl_allocate_tls (dl-tls.c:530)
==38649== by 0x4E44227: allocate_stack (allocatestack.c:627)
==38649== by 0x4E44227: pthread_create##GLIBC_2.2.5 (pthread_create.c:644)
==38649== by 0x108902: main (2.c:18)
==38649==
==38649== LEAK SUMMARY:
==38649== definitely lost: 0 bytes in 0 blocks
==38649== indirectly lost: 0 bytes in 0 blocks
==38649== possibly lost: 272 bytes in 1 blocks
==38649== still reachable: 0 bytes in 0 blocks
==38649== suppressed: 0 bytes in 0 blocks
==38649==
==38649== For counts of detected and suppressed errors, rerun with: -v
==38649== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Your expectation is correct that there shouldn't be any leaks in main thread once you call pthread_exit.
However, what you observe is a quirk of the implementation you're using (which is likely to be glibc) - pthreads library (glibc implementation) re-uses the initially allocated stack for threads - like a cache so that previously allocated stacks can be re-used whenever possible.
Valgrind simply reports what it "sees" (something was allocated but not de-allocated). But it's not a real leak, so you don't need to worry about this.
If you "reverse" the logic (main thread exits as the last thread) then you wouldn't see leaks because the initially allocated stack space is properly free'd by the main thread. But this leak isn't a real leak in any case and you can safely ignore this.
You can also setup a suppression file so that Valgrind doesn't complain about this (which is to inform Valgrind that "I know this isn't not real leak, so don't report this"), such as:
{
Pthread_Stack_Leaks_Ignore
Memcheck:Leak
fun:calloc
fun:allocate_dtv
fun:_dl_allocate_tls
fun:allocate_stack
fun:pthread_create*
}
I am confused about the behaviour of malloc_trim as implemented in the glibc.
man malloc_trim
[...]
malloc_trim - release free memory from the top of the heap
[...]
This function cannot release free memory located at places other than the top of the heap.
When I now look up the source of malloc_trim() (in malloc/malloc.c) I see that it calls mtrim() which is utilizing madvise(x, MADV_DONTNEED) to release memory back to the operating system.
So I wonder if the man-page is wrong or if I misinterpret the source in malloc/malloc.c.
Can malloc_trim() release memory from the middle of the heap?
There are two usages of madvise with MADV_DONTNEED in glibc now: http://code.metager.de/source/search?q=MADV_DONTNEED&path=%2Fgnu%2Fglibc%2Fmalloc%2F&project=gnu
H A D arena.c 643 __madvise ((char *) h + new_size, diff, MADV_DONTNEED);
H A D malloc.c 4535 __madvise (paligned_mem, size & ~psm1, MADV_DONTNEED);
There was https://sourceware.org/git/?p=glibc.git;a=commit;f=malloc/malloc.c;h=68631c8eb92ff38d9da1ae34f6aa048539b199cc commit by Ulrich Drepper on 16 Dec 2007 (part of glibc 2.9 and newer):
malloc/malloc.c (public_mTRIm): Iterate over all arenas and call
mTRIm for all of them.
(mTRIm): Additionally iterate over all free blocks and use madvise
to free memory for all those blocks which contain at least one
memory page.
mTRIm (now mtrim) implementation was changed. Unused parts of chunks, aligned on page size and having size more than page may be marked as MADV_DONTNEED:
/* See whether the chunk contains at least one unused page. */
char *paligned_mem = (char *) (((uintptr_t) p
+ sizeof (struct malloc_chunk)
+ psm1) & ~psm1);
assert ((char *) chunk2mem (p) + 4 * SIZE_SZ <= paligned_mem);
assert ((char *) p + size > paligned_mem);
/* This is the size we could potentially free. */
size -= paligned_mem - (char *) p;
if (size > psm1)
madvise (paligned_mem, size & ~psm1, MADV_DONTNEED);
Man page of malloc_trim is there: https://github.com/mkerrisk/man-pages/blob/master/man3/malloc_trim.3 and it was committed by kerrisk in 2012: https://github.com/mkerrisk/man-pages/commit/a15b0e60b297e29c825b7417582a33e6ca26bf65
As I can grep the glibc's git, there are no man pages in the glibc, and no commit to malloc_trim manpage to document this patch. The best and the only documentation of glibc malloc is its source code: https://sourceware.org/git/?p=glibc.git;a=blob;f=malloc/malloc.c
Additional functions:
malloc_trim(size_t pad);
609 /*
610 malloc_trim(size_t pad);
611
612 If possible, gives memory back to the system (via negative
613 arguments to sbrk) if there is unused memory at the `high' end of
614 the malloc pool. You can call this after freeing large blocks of
615 memory to potentially reduce the system-level memory requirements
616 of a program. However, it cannot guarantee to reduce memory. Under
617 some allocation patterns, some large free blocks of memory will be
618 locked between two used chunks, so they cannot be given back to
619 the system.
620
621 The `pad' argument to malloc_trim represents the amount of free
622 trailing space to leave untrimmed. If this argument is zero,
623 only the minimum amount of memory to maintain internal data
624 structures will be left (one page or less). Non-zero arguments
625 can be supplied to maintain enough trailing space to service
626 future expected allocations without having to re-obtain memory
627 from the system.
628
629 Malloc_trim returns 1 if it actually released any memory, else 0.
630 On systems that do not support "negative sbrks", it will always
631 return 0.
632 */
633 int __malloc_trim(size_t);
634
Freeing from the middle of the chunk is not documented as text in malloc/malloc.c (and malloc_trim description in commend was not updated in 2007) and not documented in man-pages project. Man page from 2012 may be the first man page of the function, written not by authors of glibc. Info page of glibc only mentions M_TRIM_THRESHOLD of 128 KB:
https://www.gnu.org/software/libc/manual/html_node/Malloc-Tunable-Parameters.html#Malloc-Tunable-Parameters and don't list malloc_trim function https://www.gnu.org/software/libc/manual/html_node/Summary-of-Malloc.html#Summary-of-Malloc (and it also don't document memusage/memusagestat/libmemusage.so).
You may ask Drepper and other glibc developers again as you already did in https://sourceware.org/ml/libc-help/2015-02/msg00022.html "malloc_trim() behaviour", but there is still no reply from them. (Only wrong answers from other users like https://sourceware.org/ml/libc-help/2015-05/msg00007.html https://sourceware.org/ml/libc-help/2015-05/msg00008.html)
Or you may test the malloc_trim with this simple C program (test_malloc_trim.c) and strace/ltrace:
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <malloc.h>
int main()
{
int *m1,*m2,*m3,*m4;
printf("%s\n","Test started");
m1=(int*)malloc(20000);
m2=(int*)malloc(40000);
m3=(int*)malloc(80000);
m4=(int*)malloc(10000);
printf("1:%p 2:%p 3:%p 4:%p\n", m1, m2, m3, m4);
free(m2);
malloc_trim(0); // 20000, 2000000
sleep(1);
free(m1);
free(m3);
free(m4);
// malloc_stats(); malloc_info(0, stdout);
return 0;
}
gcc test_malloc_trim.c -o test_malloc_trim, strace ./test_malloc_trim
write(1, "Test started\n", 13Test started
) = 13
brk(0) = 0xcca000
brk(0xcef000) = 0xcef000
write(1, "1:0xcca010 2:0xccee40 3:0xcd8a90"..., 441:0xcca010 2:0xccee40 3:0xcd8a90 4:0xcec320
) = 44
madvise(0xccf000, 36864, MADV_DONTNEED) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0}, 0x7ffffafbfff0) = 0
brk(0xceb000) = 0xceb000
So, there is madvise with MADV_DONTNEED for 9 pages after malloc_trim(0) call, when there was hole of 40008 bytes in the middle of the heap.
... utilizing madvise(x, MADV_DONTNEED) to release memory back to the
operating system.
madvise(x, MADV_DONTNEED) does not release memory. man madvise:
MADV_DONTNEED
Do not expect access in the near future. (For the time being,
the application is finished with the given range, so the kernel
can free resources associated with it.) Subsequent accesses of
pages in this range will succeed, but will result either in
reloading of the memory contents from the underlying mapped file
(see mmap(2)) or zero-fill-on-demand pages for mappings without
an underlying file.
So, the usage of madvise(x, MADV_DONTNEED) does not contradict man malloc_trim's statement:
This function cannot release free memory located at places other than the top of the heap.
I have a very simple CUDA component in my application. Valgrind reports a lot of leaks and still-reachables, all related to the cudaMalloc calls.
Are these leaks real? I call cudaFree for every cudaMalloc. Is this valgrind's inability to interpret GPU memory allocation? If these leaks are not real, can I suppress them and have valgrind only analyse the non-gpu part of the application?
extern "C"
unsigned int *gethash(int nodec, char *h_nodev, int len) {
unsigned int *h_out = (unsigned int *)malloc(sizeof(unsigned int) * nodec);
char *d_in;
unsigned int *d_out;
cudaMalloc((void**) &d_in, sizeof(char) * len * nodec);
cudaMalloc((void**) &d_out, sizeof(unsigned int) * nodec);
cudaMemcpy(d_in, h_nodev, sizeof(char) * len * nodec, cudaMemcpyHostToDevice);
int blocks = 1 + nodec / 512;
cube<<<blocks, 512>>>(d_out, d_in, nodec, len);
cudaMemcpy(h_out, d_out, sizeof(unsigned int) * nodec, cudaMemcpyDeviceToHost);
cudaFree(d_in);
cudaFree(d_out);
return h_out;
}
Last bit of the Valgrind output:
...
==5727== 5,468 (5,020 direct, 448 indirect) bytes in 1 blocks are definitely lost in loss record 506 of 523
==5727== at 0x402B965: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==5727== by 0x4843910: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x48403E9: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x498B32D: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x494A6E4: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x4849534: ??? (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x48191DD: cuInit (in /usr/lib/nvidia-319-updates/libcuda.so.319.60)
==5727== by 0x406B4D6: ??? (in /usr/lib/i386-linux-gnu/libcudart.so.5.0.35)
==5727== by 0x406B61F: ??? (in /usr/lib/i386-linux-gnu/libcudart.so.5.0.35)
==5727== by 0x408695D: cudaMalloc (in /usr/lib/i386-linux-gnu/libcudart.so.5.0.35)
==5727== by 0x804A006: gethash (hashkernel.cu:36)
==5727== by 0x804905F: chkisomorphs (bdd.c:326)
==5727==
==5727== LEAK SUMMARY:
==5727== definitely lost: 10,240 bytes in 6 blocks
==5727== indirectly lost: 1,505 bytes in 54 blocks
==5727== possibly lost: 7,972 bytes in 104 blocks
==5727== still reachable: 626,997 bytes in 1,201 blocks
==5727== suppressed: 0 bytes in 0 blocks
It's a known issue that valgrind reports false-positives for a bunch of CUDA stuff. The best way to avoid seeing it would be to use valgrind suppressions, which you can read all about here:
http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress
If you want to jumpstart into something a little closer to your specific issue, an interesting post is this one on the Nvidia dev forums. It has a link to a sample suppression rule file.
https://devtalk.nvidia.com/default/topic/404607/valgrind-3-4-suppressions-a-little-howto/
Try using cuda-memcheck --leak-check full. Cuda-memcheck is a set of tools that provides similar functionality to Valgrind for CUDA applications. It is installed as part of the CUDA toolkit. You can get more documentation about how to use cuda-memcheck here : http://docs.nvidia.com/cuda/cuda-memcheck/
Note that cuda-memcheck is not a direct replacement for valgrind and can't be used to detect host side memory leaks or buffer overflows.
To add to scarl3tt's answer, this may be overly general for some applications, but if you want to use valgrind while ignoring most of the cuda issues, use the option --suppressions=valgrind-cuda.supp where valgrind-cuda.supp is a file with the following rules:
{
alloc_libcuda
Memcheck:Leak
match-leak-kinds: reachable,possible
fun:*alloc
...
obj:*libcuda.so*
...
}
{
alloc_libcufft
Memcheck:Leak
match-leak-kinds: reachable,possible
fun:*alloc
...
obj:*libcufft.so*
...
}
{
alloc_libcudaart
Memcheck:Leak
match-leak-kinds: reachable,possible
fun:*alloc
...
obj:*libcudart.so*
...
}
I wouldn't trust valgrind or any other leak detector (like VLD) with CUDA. I'm sure they weren't designed with GPU allocations in mind. I don't know whether Nvidia's Nsight has the capability these days (I haven't done GPU programming for almost 6 months now), but that's the best thing I used for CUDA debugging, and to be quite honest, it was buggy as hell.
The code you've posted shouldn't create a leak.
Since I don't have 50 reputation, I cannot leave a comment on #Vyas 's answer.
I feel strange that cuda-memcheck cannot observe cuda memory leakage.
I just write a very simple code with a cuda memory leakage, but when using cuda-memcheck --leak-check full it give no leakage. It is:
#include <iostream>
#include <cuda_runtime.h>
using namespace std;
int main(){
float* cpu_data;
float* gpu_data;
int buf_size = 10 * sizeof(float);
cpu_data = (float*)malloc(buf_size);
for(int i=0; i<10; i++){
cpu_data[i] = 1.0f * i;
}
cudaError_t cudaStatus = cudaMalloc(&gpu_data, buf_size);
cudaMemcpy(gpu_data, cpu_data, buf_size, cudaMemcpyHostToDevice);
free(cpu_data);
//cudaFree(gpu_data);
return 0;
}
Note the commented line of code, which make this program a cuda memory leakage, I think. However, when execuing cuda-memcheck ./a.out it gives:
========= CUDA-MEMCHECK
========= ERROR SUMMARY: 0 errors
I've get a memory leak reported by Valgrind with -pg enabled when compiling the following simple code.
#include <iostream>
#include <boost/filesystem.hpp>
#define BOOST_FILESYSTEM_VERSION 3
using boost::filesystem::path;
using namespace std;
int main() {
path ptDir;
ptDir = "/home/foo/bar";
if (true == is_directory((const path &)ptDir)){
cout << "ptDir: " << ptDir << endl;
}
}
The full compile option was as follows.
g++ -pg -g test.cpp -lboost_system -lboost_filesystem
The command of running valgrind is:
valgrind --gen-suppressions=all --track-origins=yes --error-limit=no --leak-check=full --show-reachable=yes -v --trace-children=yes --track-fds=yes --log-file=vg.log ./a.out
Then valgrind gave me a memory leak error.
==9598== HEAP SUMMARY:
==9598== in use at exit: 4,228 bytes in 1 blocks
==9598== total heap usage: 136 allocs, 135 frees, 17,984 bytes allocated
==9598==
==9598== Searching for pointers to 1 not-freed blocks
==9598== Checked 130,088 bytes
==9598==
==9598== 4,228 bytes in 1 blocks are still reachable in loss record 1 of 1
==9598== at 0x402A5E6: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==9598== by 0x4260F44: monstartup (gmon.c:134)
==9598== by 0xBED6B636: ???
==9598== by 0x4E45504E: ???
==9598==
{
<insert_a_suppression_name_here>
Memcheck:Leak
fun:calloc
fun:monstartup
obj:*
obj:*
}
==9598== LEAK SUMMARY:
==9598== definitely lost: 0 bytes in 0 blocks
==9598== indirectly lost: 0 bytes in 0 blocks
==9598== possibly lost: 0 bytes in 0 blocks
==9598== still reachable: 4,228 bytes in 1 blocks
==9598== suppressed: 0 bytes in 0 blocks
==9598==
==9598== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==9598== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Is this correct? I'm using Ubuntu 12.04/ Kernel 3.2.0-32-generic
Valgrind FAQ:
"still reachable" means your program is probably ok -- it didn't free some
memory it could have. This is quite common and often reasonable. Don't use
--show-reachable=yes if you don't want to see these reports.
The fact that the allocatio comes from:
by 0x4260F44: monstartup (gmon.c:134)
indicates that it's a side effect of -pg - which is nothing you can do anything about. Don't mix -pg and valgrind is my suggestion.
I've been chasing a memory leak (reported by 'valgrind --leak-check=yes') and it appears to be coming from ALSA. This code has been in the free world for some time so I'm guessing that it's something I'm doing wrong.
#include <stdio.h>
#include <stdlib.h>
#include <alsa/asoundlib.h>
int main (int argc, char *argv[])
{
snd_ctl_t *handle;
int err = snd_ctl_open( &handle, "hw:1", 0 );
printf( "snd_ctl_open: %d\n", err );
err = snd_ctl_close(handle);
printf( "snd_ctl_close: %d\n", err );
}
The output looks like this:
[root#aeolus alsa]# valgrind --leak-check=yes ./test2
==16296== Memcheck, a memory error detector
==16296== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==16296== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==16296== Command: ./test2
==16296==
snd_ctl_open: 0
snd_ctl_close: 0
==16296==
==16296== HEAP SUMMARY:
==16296== in use at exit: 22,912 bytes in 1,222 blocks
==16296== total heap usage: 1,507 allocs, 285 frees, 26,236 bytes allocated
==16296==
==16296== 4 bytes in 2 blocks are possibly lost in loss record 1 of 62
==16296== at 0x4007100: malloc (vg_replace_malloc.c:270)
==16296== by 0x340F7F: strdup (in /lib/libc-2.5.so)
==16296== by 0x624C6B5: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CA5B: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CD81: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624F311: snd_config_update_r (in /lib/libasound.so.2.0.0)
==16296== by 0x624FAD7: snd_config_update (in /lib/libasound.so.2.0.0)
==16296== by 0x625DA22: snd_ctl_open (in /lib/libasound.so.2.0.0)
==16296== by 0x804852F: main (test2.cpp:9)
and continues for some pages to
==16296== 2,052 bytes in 57 blocks are possibly lost in loss record 62 of 62
==16296== at 0x4005EB4: calloc (vg_replace_malloc.c:593)
==16296== by 0x624A268: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624A38F: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CA33: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CCC9: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624CD81: ??? (in /lib/libasound.so.2.0.0)
==16296== by 0x624F311: snd_config_update_r (in /lib/libasound.so.2.0.0)
==16296== by 0x624FAD7: snd_config_update (in /lib/libasound.so.2.0.0)
==16296== by 0x625DA22: snd_ctl_open (in /lib/libasound.so.2.0.0)
==16296== by 0x804852F: main (test2.cpp:9)
==16296==
==16296== LEAK SUMMARY:
==16296== definitely lost: 0 bytes in 0 blocks
==16296== indirectly lost: 0 bytes in 0 blocks
==16296== possibly lost: 22,748 bytes in 1,216 blocks
==16296== still reachable: 164 bytes in 6 blocks
==16296== suppressed: 0 bytes in 0 blocks
==16296== Reachable blocks (those to which a pointer was found) are not shown.
==16296== To see them, rerun with: --leak-check=full --show-reachable=yes
==16296==
==16296== For counts of detected and suppressed errors, rerun with: -v
==16296== ERROR SUMMARY: 56 errors from 56 contexts (suppressed: 19 from 8)
This came about as I'm using ALSA in a project and started seeing this huge leak...or at least the report of said leak.
So the question is: is it me, ALSA or valgrind that's having issues here?
http://git.alsa-project.org/?p=alsa-lib.git;a=blob;f=MEMORY-LEAK;hb=HEAD says:
Memory leaks - really?
----------------------
Note that some developers are thinking that the ALSA library has some memory
leaks. Sure, it can be truth, but before contacting us, please, be sure that
these leaks are not forced.
The biggest reported leak is that the global configuration is cached for
next usage. If you do not want this feature, simply, call
snd_config_update_free_global() after all snd_*_open*() calls. This function
will free the cache.
The biggest reported leak is that the global configuration is cached for next usage.
If you do not want this feature, simply call snd_config_update_free_global() after all snd_*_open*() calls.
This function will free the cache." <---- Valgrind still detects leaks.
This can be fixed if you call snd_config_update_free_global() after snd_pcm_close(handle);
Perhaps this will work (source):
diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c
--- a/src/pcm/pcm.c
+++ b/src/pcm/pcm.c
## -2171,7 +2171,12 ## static int snd_pcm_open_conf(snd_pcm_t **pcmp, const char *name,
if (open_func) {
err = open_func(pcmp, name, pcm_root, pcm_conf, stream, mode);
if (err >= 0) {
- (*pcmp)->open_func = open_func;
+ if ((*pcmp)->open_func) {
+ /* only init plugin (like empty, asym) */
+ snd_dlobj_cache_put(open_func);
+ } else {
+ (*pcmp)->open_func = open_func;
+ }
err = 0;
} else {
snd_dlobj_cache_put(open_func);
I tried it myself, but to no avail. My core temp heats up ~10 °F, most likely due to similar memory leak. Here's some of what valgrind gave me, even after using the patch above:
==869== 16,272 bytes in 226 blocks are possibly lost in loss record 103 of 103
==869== at 0x4C28E48: calloc (vg_replace_malloc.c:566)
==869== by 0x5066E61: _snd_config_make (in /usr/lib64/libasound.so.2)
==869== by 0x5066F58: _snd_config_make_add (in /usr/lib64/libasound.so.2)
==869== by 0x50673B9: parse_value (in /usr/lib64/libasound.so.2)
==869== by 0x50675DE: parse_array_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067680: parse_array_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A8E: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
==869== by 0x5067A6F: parse_def (in /usr/lib64/libasound.so.2)
==869== by 0x5067BC7: parse_defs (in /usr/lib64/libasound.so.2)
The number of bytes lost just keeps going up and up.