Memory leaks in pthread even if the state is detached - linux

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*
}

Related

While running, is it possible to display the currently allocated buffers managed by LeakSanitizer?

I've a very large program (okay, only 13,000 lines of code according to cloc) which leaks. I know because over time, it uses more and more resident memory.
I have the sanitizer option turned on, but on a clean exit, all my C++ software will properly clean everything as expected. So I don't see anything growing in the sanitizer output.
What would be useful in this case, is a way to call a function which displays the (large) list of allocated buffers while running the code. I can then look at a diff of two such outputs and see what was allocated anew. The leaked buffers will be in there...
At this point, though, I just don't see any header with sanitizer functions I could call to see such a list. Does it exist?
Lsan interface is available in sanitizer/lsan_interface.h but AFAIK it has no API to print allocation info. The best you can get is compile your code with Asan (which includes Lsan as well) and use __asan_print_accumulated_stats to get basic allocation statistics:
$ cat tmp.c
#include <sanitizer/asan_interface.h>
#include <stdlib.h>
int main() {
malloc(100);
__asan_print_accumulated_stats();
return 0;
}
$ gcc -fsanitize=address -g tmp.c && ./a.out
Stats: 0M malloced (0M for red zones) by 2 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (0M-0M) mmaped; 5 maps, 0 unmaps
mallocs by size class: 7:1; 11:1;
Stats: malloc large: 0
Stats: StackDepot: 2 ids; 0M allocated
Stats: SizeClassAllocator64: 0M mapped in 256 allocations; remains 256
07 (112): mapped: 64K allocs: 128 frees: 0 inuse: 128 num_freed_chunks 457 avail: 585 rss: 4K releases: 0
11 (176): mapped: 64K allocs: 128 frees: 0 inuse: 128 num_freed_chunks 244 avail: 372 rss: 4K releases: 0
Stats: LargeMmapAllocator: allocated 0 times, remains 0 (0 K) max 0 M; by size logs:
=================================================================
==15060==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 100 byte(s) in 1 object(s) allocated from:
#0 0x7fdf2194fb40 in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdeb40)
#1 0x559ca08a7857 in main /home/yugr/tmp.c:5
#2 0x7fdf214a1bf6 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21bf6)
SUMMARY: AddressSanitizer: 100 byte(s) leaked in 1 allocation(s).
Unfortunately there is no way to print exact allocations.

Valgrind and CUDA: Are reported leaks real?

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

valgrind | self-made garbage collection | bytes in 1 blocks are definitely lost in loss record

I write a quite complex software (for > 10 years by now).
You may want to checkout sources from:
http://savannah.nongnu.org/svn/?group=cybop
Follow the instructions of the INSTALL file to compile and run.
I've run memcheck using this command line:
christian#deneb:/home/project/cybop/examples$ valgrind --tool=memcheck --log-file=memcheck.log --leak-check=full --track-origins=yes ../src/controller/cyboi exit/run.cybol
Here is the memcheck output:
==28641== Memcheck, a memory error detector
==28641== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==28641== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==28641== Command: ../src/controller/cyboi exit/run.cybol
==28641== Parent PID: 22974
==28641==
==28641==
==28641== HEAP SUMMARY:
==28641== in use at exit: 5,174 bytes in 407 blocks
==28641== total heap usage: 636 allocs, 229 frees, 45,749 bytes allocated
==28641==
==28641== 442 (72 direct, 370 indirect) bytes in 1 blocks are definitely lost in loss record 406 of 407
==28641== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==28641== by 0x401EC0: allocate_array (array_allocator.c:116)
==28641== by 0x40719C: allocate_part (part_allocator.c:50)
==28641== by 0x42EE3E: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:262)
==28641== by 0x43098E: deserialise_cybol_part_element (element_part_cybol_deserialiser.c:74)
==28641== by 0x4309FD: deserialise_cybol_part (part_cybol_deserialiser.c:79)
==28641== by 0x42F230: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:331)
==28641== by 0x43098E: deserialise_cybol_part_element (element_part_cybol_deserialiser.c:74)
==28641== by 0x4309FD: deserialise_cybol_part (part_cybol_deserialiser.c:79)
==28641== by 0x42F230: deserialise_cybol_part_element_content (content_element_part_cybol_deserialiser.c:331)
==28641== by 0x42F4CB: deserialise_cybol (cybol_deserialiser.c:196)
==28641== by 0x42FD48: deserialise (deserialiser.c:229)
==28641==
==28641== 4,732 (72 direct, 4,660 indirect) bytes in 1 blocks are definitely lost in loss record 407 of 407
==28641== at 0x4C28BED: malloc (vg_replace_malloc.c:263)
==28641== by 0x401EC0: allocate_array (array_allocator.c:116)
==28641== by 0x40719C: allocate_part (part_allocator.c:50)
==28641== by 0x41F6EA: deserialise_xml_element (element_xml_deserialiser.c:61)
==28641== by 0x41FA65: select_xml_element_content (element_content_xml_selector.c:144)
==28641== by 0x41FAF3: deserialise_xml_element_content (element_content_xml_deserialiser.c:73)
==28641== by 0x41FBA9: deserialise_xml (xml_deserialiser.c:66)
==28641== by 0x42F3E1: deserialise_cybol (cybol_deserialiser.c:178)
==28641== by 0x42FD48: deserialise (deserialiser.c:229)
==28641== by 0x430088: receive_file (file_receiver.c:106)
==28641== by 0x433D2F: initialise (initialiser.c:88)
==28641== by 0x4344C3: manage (manager.c:320)
==28641==
==28641== LEAK SUMMARY:
==28641== definitely lost: 144 bytes in 2 blocks
==28641== indirectly lost: 5,030 bytes in 405 blocks
==28641== possibly lost: 0 bytes in 0 blocks
==28641== still reachable: 0 bytes in 0 blocks
==28641== suppressed: 0 bytes in 0 blocks
==28641==
==28641== For counts of detected and suppressed errors, rerun with: -v
==28641== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
The "definitely lost" error claims not everything was freed properly.
I don't ask you to do the Sisyphus job and search all my source code.
There is essentially just one "malloc" that all functions rely on.
The data structures (top-down) are as follows: part - item - array - value,
i. e. a part references nine items, and an item references three arrays.
My self-made built-in garbage collection says everything were fine.
Perhaps somebody wants to have a look? Any hint is appreciated.
Source code snippet of file "array_allocator.c" following:
void allocate_array(void* p0, void* p1, void* p2) {
if (p0 != *NULL_POINTER_STATE_CYBOI_MODEL) {
void** a = (void**) p0;
// The memory area.
int ma = *NUMBER_0_INTEGER_STATE_CYBOI_MODEL;
// Determine type (type) size.
determine_size((void*) &ma, p2);
// Calculate memory area.
calculate_integer_multiply((void*) &ma, p1);
// The temporary size_t variable.
size_t tma = ma;
// CAUTION! In order to always get a correct memory address returned
// that may be used to store data, a potential zero size is changed
// to a minimum size of one here.
if (tma == *NUMBER_0_INTEGER_STATE_CYBOI_MODEL) {
tma = *NUMBER_1_INTEGER_STATE_CYBOI_MODEL;
} else if (tma < *NUMBER_0_INTEGER_STATE_CYBOI_MODEL) {
fwprintf(stdout, L"ERROR: Could not allocate array. The memory area to be allocated is negative: %i\n", *a);
tma = *NUMBER_1_INTEGER_STATE_CYBOI_MODEL;
}
*a = malloc(tma);
// Initialise array elements with null pointer.
//
// CAUTION! Initialising with zero values is essential, since
// cyboi frequently tests variables for null pointer values.
memset(*a, *NUMBER_0_INTEGER_STATE_CYBOI_MODEL, tma);
} else {
log_message_terminated((void*) ERROR_LEVEL_LOG_CYBOI_MODEL, (void*) L"Could not allocate array. The array is null.");
}
}
Asking this question here was a mistake, since it does not
touch programming in general, but rather project-specific
issues.
I finally found the bug. It was a logical error.
When deallocating a (self-defined) "part" structure,
the "type" of "model" is needed. The error was that
I deallocated a part's "type" before the actual "model",
so that "model" deallocation did not work correctly
and memory leaks occured.
Solved. Does not belong into stackoverflow. Just to close it.

Valgrind has reported "memory leak" when I compiled my program with "-pg" enabled?

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.

alsa - mem leak?

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.

Resources