# Memory leak in C caused by FMOD\_System\_Init()

**URL:** https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221
**Category:** FMOD Engine
**Created:** [September 25, 2020, 1:14pm UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221 "2020-09-25T13:14:59Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![Bubba](https://avatars.discourse-cdn.com/v4/letter/b/e9a140/32.png) [@Bubba](https://qa.fmod.com/u/Bubba)
#### Post date: [September 25, 2020, 1:14pm UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221/1 "2020-09-25T13:14:59Z")

</div>

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.

```auto
#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

```auto
$ 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)

```

---

<div class="post-metadata">

### Author: ![tristanjl](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/tristanjl/32/261_2.png) [@tristanjl](https://qa.fmod.com/u/tristanjl)
#### Post date: [September 28, 2020, 11:43pm UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221/2 "2020-09-28T23:43:20Z")

</div>

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

---

<div class="post-metadata">

### Author: ![Bubba](https://avatars.discourse-cdn.com/v4/letter/b/e9a140/32.png) [@Bubba](https://qa.fmod.com/u/Bubba)
#### Post date: [October 5, 2020, 8:47am UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221/3 "2020-10-05T08:47:15Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![tristanjl](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/tristanjl/32/261_2.png) [@tristanjl](https://qa.fmod.com/u/tristanjl)
#### Post date: [October 5, 2020, 10:59pm UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221/4 "2020-10-05T22:59:45Z")

</div>

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

---

<div class="post-metadata">

### Author: ![ggjulio](https://avatars.discourse-cdn.com/v4/letter/g/ecb155/32.png) [@ggjulio](https://qa.fmod.com/u/ggjulio)
#### Post date: [March 27, 2021, 12:26pm UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221/6 "2021-03-27T12:26:05Z")

</div>

Hi,

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

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

```

```auto
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

---

<div class="post-metadata">

### Author: ![tristanjl](https://yyz2.discourse-cdn.com/flex036/user_avatar/qa.fmod.com/tristanjl/32/261_2.png) [@tristanjl](https://qa.fmod.com/u/tristanjl)
#### Post date: [March 30, 2021, 6:04am UTC](https://qa.fmod.com/t/memory-leak-in-c-caused-by-fmod-system-init/16221/7 "2021-03-30T06:04:49Z")

</div>

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.
