memory leaks

[hu8813]

hi, thanks for the library. how can i free it so that i don't have memory leaks, i have still reacable and not freed memory

i use as following:

#define MINIAUDIO_IMPLEMENTATION
#include "./miniaudio.h"

#include <stdio.h>

int main(int argc, char** argv)
{
    ma_result result;
    ma_engine engine;

    result = ma_engine_init(NULL, &engine);
    if (result != MA_SUCCESS) {
        printf("Failed to initialize audio engine.");
        return -1;
    }

    ma_engine_play_sound(&engine, "play.mp3", NULL);

    printf("Press Enter to quit...");
    getchar();

    ma_engine_uninit(&engine);

    return 0;
}

still reachable: 72,967 bytes in 193 blocks HEAP SUMMARY: ==442082== in use at exit: 72,967 bytes in 193 blocks ==442082== total heap usage: 49,857 allocs, 49,665 frees, 5,013,169 bytes allocated

[mackron]

What's the unfreed memory allocation? Your report only mentions that there's still memory around but not the specific allocation.

[hu8813]

i am very beginner with C, i do not know what you mean with that. but valgrind says there are unfreed heap in 193 blocks. how can i free that, i do not know

[mackron]

So memory will be allocated with something like malloc(), and most memory leak detectors will track each of those calls so that you can see exactly which of those do not have a corresponding free(). I don't know how to configure Valgrind to display that information.

Are you able to try the simple_playback_sine example? That will narrow it down a little bit.

It could also be that the backend itself is holding onto memory in which case miniaudio can't really do much about that.

What platform are you running on?

[hu8813]

using ubuntu linux i do not malloc or free, my code is only as in first post which i copied from your examples. compiled with flags: gcc test.c -ldl -lpthread -lm unfortunately here is valgrind output:

valgrind ./a.out play.mp3

==492028== Memcheck, a memory error detector
==492028== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==492028== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info
==492028== Command: ./a.out play.mp3
==492028== 
Press Enter to quit...^[
==492028== 
==492028== HEAP SUMMARY:
==492028==     in use at exit: 82,160 bytes in 217 blocks
==492028==   total heap usage: 1,077 allocs, 860 frees, 1,411,800 bytes allocated
==492028== 
==492028== LEAK SUMMARY:
==492028==    definitely lost: 0 bytes in 0 blocks
==492028==    indirectly lost: 0 bytes in 0 blocks
==492028==      possibly lost: 0 bytes in 0 blocks
==492028==    still reachable: 82,160 bytes in 217 blocks
==492028==         suppressed: 0 bytes in 0 blocks
==492028== Rerun with --leak-check=full to see details of leaked memory
==492028== 
==492028== For lists of detected and suppressed errors, rerun with: -s
==492028== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0

[mackron]

I've tested this on my end and have found no memory leaks with simple_playback originating from miniaudio code. See screenshots below. The first one is the baseline. You can see 6 memory allocations totalling 85,975 bytes. The second screenshot is a snapshot at the end of running the program which show how each of those allocations have been offset which means they've been freed.

There are other allocations mentioned in the report, but they're all made internally by the operating system. For example, the screenshot below shows a memory allocation which was triggered from miniaudio, but it was allocated internally by the operating system. There's nothing miniaudio can do about that. My suspicion is that the leaks reported by your report are allocations miniaudio has no control over. If indeed they're directly from miniaudio I'll address it, but I haven't seen any evidence that this is coming from miniaudio directly.