0

Environment: Ubuntu 11.04. SDL 1.2.15.

In my SDL based application, I play multiple video clips one after another. For each video, I call SDL_OpenAudio at the start and SDL_CloseAudio at the end. However, each round leaves two blocks of memory unfreed. Both of them are coming from internal SDL function AudioAvailable.



==17035== 372 bytes in 3 blocks are definitely lost in loss record 139 of 169
==17035==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==17035==    by 0xB2B0564: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==17035==    by 0xB2B062A: ??? (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==17035==    by 0xB2B01CA: xcb_connect_to_display_with_auth_info (in /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0)
==17035==    by 0xCC650ED: pa_client_conf_from_x11 (in /usr/lib/x86_64-linux-gnu/libpulsecommon-1.0.so)
==17035==    by 0xC9ED83E: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.13.4)
==17035==    by 0xC7DD9F2: pa_simple_new (in /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0.0.3)
==17035==    by 0x418AED: Audio_Available (SDL_pulseaudio.c:235)
==17035==    by 0x405893: SDL_AudioInit (SDL_audio.c:360)
==17035==    by 0x404A79: SDL_InitSubSystem (SDL.c:105)
==17035==    by 0x405E59: SDL_OpenAudio (SDL_audio.c:404)

I am wondering if there is something that I could be doing wrong in my code. I have verified that SDL_CloseAudio is indeed being called.

genpfault
  • 51,148
  • 11
  • 85
  • 139
Peter
  • 11,260
  • 14
  • 78
  • 155
  • Anyone? Please help. Earlier, I thought I could call SDL_OpenAudio just once. However, I don't see any other API to change the desired audio specs. Regars, Peter. – Peter Jun 09 '12 at 06:44
  • We don't work with SDL, but pulseaudio,`pa_context_new_with_proplist` pops up in your traceback, and the same function causes memleaks with us as well. I am still investigating, but first investigation shows some similar bugs in the bugtracker for pulseaudio, like https://bugs.freedesktop.org/show_bug.cgi?id=42942 . This memleak seems to appear at a different point, but does not make too much hope: The leak referenced in the bug report seems 'unavoidable due to threading issues'. Hope that's not the cause for this leak as well... – Michael Beer May 07 '20 at 10:28

1 Answers1

-1

I'm not an expert on SDL or OpenGL by any means, but I think that most software will leak memory at one point or another. See this post for more info: Why does valgrind say basic SDL program is leaking memory?

On the bright side, SDL is only leaking 374 bytes, which is pennies compared to what most systems offer. It shouldn't make a big difference in the long run.

Community
  • 1
  • 1
Richard
  • 242
  • 2
  • 11
  • Thanks Richard. In our case, the video clips are shown 24/7. If SDL continues to leak each time, we will eventually run out of memory. – Peter Jun 25 '12 at 09:27
  • Sorry, but ths is really not only not helpful, it furthermore directs onto the entirely wrong path: Accepting that software leaks memory. Memleaks are amongst the worst kind of errors (only topped by inflicting undefined behaviour), for if they go undetected, they will cause crashes 'out of nowhere' and are really hard to debug once you let them spread into your code. – Michael Beer May 07 '20 at 10:27