Memory leak in C caused by FMOD_System_Init()

Hi, I am using FMOD Api 2.1 and I am encountering a problem with memory leaks with the function FMOD_System_Init(). I don’t know if anything else is supposed to be done before releasing memory. I have commented FMOD_System_Init() and I only had 5 allocs and 5 frees, no leaks.

#include <stdio.h>
#include <stdlib.h>
#include "inc/fmod.h"

int main (){
   FMOD_SYSTEM *system;
   FMOD_System_Create(&system);
   FMOD_System_Init(system, 1, FMOD_INIT_NORMAL, NULL);
   FMOD_System_Release(system);
   return 0;
}

I must say that I have removed code and reexecuted the output. With more code I am still getting the same quantity of memory leaked.

Valgrind, when executing without flags

$ valgrind ./a.out 
==20161== Memcheck, a memory error detector
==20161== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==20161== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==20161== Command: ./a.out
==20161== 
==20161== 
==20161== HEAP SUMMARY:
==20161==     in use at exit: 71,218 bytes in 181 blocks
==20161==   total heap usage: 3,338 allocs, 3,157 frees, 1,150,470 bytes allocated
==20161== 
==20161== LEAK SUMMARY:
==20161==    definitely lost: 8 bytes in 2 blocks
==20161==    indirectly lost: 0 bytes in 0 blocks
==20161==      possibly lost: 0 bytes in 0 blocks
==20161==    still reachable: 71,210 bytes in 179 blocks
==20161==         suppressed: 0 bytes in 0 blocks
==20161== Rerun with --leak-check=full to see details of leaked memory
==20161== 
==20161== For lists of detected and suppressed errors, rerun with: -s
==20161== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Hi Bubba,

Using your example code, this build command: g++ -I../../ -Wl,-rpath,'$ORIGIN' ./test.cpp ./libfmod.so (plus variations for clang and logging fmod version), valgrind 3.15 and trying both alsa and pulse output modes, I was unable to reproduce your issue (with fmod 2.01.04 on ubuntu).

Which OS are you using? Which minor fmod version are you using? Do you have any other instrumentation/using any other build configuration settings?

Thanks
Tristan

Hi tristanjl,
I compiled in c,

gcc test.c -Wl,-rpath=./lib/x86_64 -L./lib/x86_64 -lfmod

and i get as output:

/usr/bin/ld: ./lib/x86_64/libfmod.so: .dynsym local symbol at index 2 (>= sh_info of 2)
/usr/bin/ld: ./lib/x86_64/libfmod.so: .dynsym local symbol at index 3 (>= sh_info of 2)
/usr/bin/ld: ./lib/x86_64/libfmod.so: .dynsym local symbol at index 4 (>= sh_info of 2)

As I have understood, this was a warning.
I am using valgrind version 3.16.1, under linux.

I also downloaded the latest version of fmod api.

Hi Bubba,

There is a future scheduled change that will address those linker warnings. Unfortunately I can’t confirm when that will be available.

Thanks
Tristan

Hi,

Almost the same issue, plus a conditional jump/move on uninitialised values

int main (){
   FMOD_SYSTEM *system;
   FMOD_System_Create(&system);
   FMOD_System_Init(system, 1, FMOD_INIT_NORMAL, NULL);
   FMOD_System_Release(system);
   return 0;
}
Valgrind-3.15.0

==427404== Conditional jump or move depends on uninitialised value(s)
==427404==    at 0x57EC565: pa_shm_cleanup (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==427404==    by 0x57EC7A1: pa_shm_create_rw (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==427404==    by 0x57DC4B6: pa_mempool_new (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==427404==    by 0x57619B1: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.2)
==427404==    by 0x494D694: ??? (in libfmod.so.12.8)
==427404==    by 0x494D85D: ??? (in libfmod.so.12.8)
==427404==    by 0x493CD68: ??? (in libfmod.so.12.8)
==427404==    by 0x4940FA8: ??? (in libfmod.so.12.8)
==427404==    by 0x4936202: FMOD::System::init(int, unsigned int, void*) (in libfmod.so.12.8)
==427404==    by 0x40268C: main (main.c:26)
==427404==  Uninitialised value was created by a heap allocation
==427404==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==427404==    by 0x4FDA098: __alloc_dir (opendir.c:118)
==427404==    by 0x4FDA098: opendir_tail (opendir.c:69)
==427404==    by 0x4FDA098: opendir (opendir.c:92)
==427404==    by 0x57EC52F: pa_shm_cleanup (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==427404==    by 0x57EC7A1: pa_shm_create_rw (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==427404==    by 0x57DC4B6: pa_mempool_new (in /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-13.99.so)
==427404==    by 0x57619B1: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.2)
==427404==    by 0x494D694: ??? (in libfmod.so.12.8)
==427404==    by 0x494D85D: ??? (in libfmod.so.12.8)
==427404==    by 0x493CD68: ??? (in libfmod.so.12.8)
==427404==    by 0x4940FA8: ??? (in libfmod.so.12.8)
==427404==    by 0x4936202: FMOD::System::init(int, unsigned int, void*) (in libfmod.so.12.8)
==427404==    by 0x40268C: main (main.c:26)
==427404== 
==427404== 
==427404== HEAP SUMMARY:
==427404==     in use at exit: 70,656 bytes in 176 blocks
==427404==   total heap usage: 893 allocs, 717 frees, 1,149,983 bytes allocated
==427404== 
==427404== LEAK SUMMARY:
==427404==    definitely lost: 0 bytes in 0 blocks
==427404==    indirectly lost: 0 bytes in 0 blocks
==427404==      possibly lost: 0 bytes in 0 blocks
==427404==    still reachable: 70,656 bytes in 176 blocks
==427404==         suppressed: 0 bytes in 0 blocks
==427404== Reachable blocks (those to which a pointer was found) are not shown.
==427404== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==427404== 
==427404== For lists of detected and suppressed errors, rerun with: -s
==427404== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 0 from 0)

Have a nice day

Reading through the log, the two detected errors appear to be due to pulse audio, running tests again locally I am unable to reproduce them.

Also, it appears that there were no memory leaks with your run, comparing
definitely lost: 8 bytes in 2 blocks in Bubba’s run with no similar message in your log.

As for the warning messages from before, they will be fixed in the next major version of FMOD.