Music::~Music sometimes hangs

[miki151]

I'm using SFML 2.1 and my program sometimes hangs when I call exit(0). A stack trace reveals:

#0  0xf7fdb430 in __kernel_vsyscall ()
#1  0xf7cc3e1c in pthread_join () from /lib/i386-linux-gnu/libpthread.so.0
#2  0xf7f753ab in sf::priv::ThreadImpl::wait() () from ./libsfml-system.so.2
#3  0xf7f743c8 in sf::Thread::wait() () from ./libsfml-system.so.2
#4  0xf7fd3f92 in sf::SoundStream::stop() () from ./libsfml-audio.so.2
#5  0xf7fcedf1 in sf::Music::~Music() () from ./libsfml-audio.so.2


I also get this error on start-up:
AL lib: pulseaudio.c:331: PulseAudio returned minreq > tlength/2; expect break up

This is a class that I use to handle music. Maybe I'm doing something wrong with the fact that it's a global variable. Jukebox::initialize is called from main().

#include <SFML/Audio/Music.hpp>

class Jukebox {
  public:
  enum Type { INTRO, PEACEFUL, BATTLE };
  void initialize(const string& introPath, const string& peacefulPath, const string& warPath);

  void setCurrent(Type);
  void toggle();
  void update();

  private:
  bool turnedOff();
  sf::Music& get(Type);
  unique_ptr<sf::Music[]> music;
  Type current = INTRO;
  Type currentPlaying;
  bool on = true;
};

extern Jukebox jukebox;
 

#include "music.h"

using sf::Music;

Jukebox jukebox;

void Jukebox::initialize(const string& introPath, const string& peacefulPath, const string& warPath) {
  music.reset(new Music[3]);
  music[0].openFromFile(introPath);
  music[1].openFromFile(peacefulPath);
  music[2].openFromFile(warPath);
  music[1].setLoop(true);
  music[2].setLoop(true);
  currentPlaying = current;
  if (!turnedOff())
    get(current).play();
  else
    on = false;
}

bool Jukebox::turnedOff() {
  return !Options::getValue(OptionId::MUSIC);
}

sf::Music& Jukebox::get(Type type) {
  return music[int(type)];
}

void Jukebox::toggle() {
  if ((on = !on)) {
    currentPlaying = current;
    get(current).play();
  } else
    get(current).stop();
}

void Jukebox::setCurrent(Type c) {
  if (current != INTRO)
    current = c;
}

const int volumeDec = 20;

void Jukebox::update() {
  if (turnedOff())
    return;
  if (currentPlaying == INTRO && music[0].getStatus() == sf::SoundSource::Stopped) {
    currentPlaying = current = PEACEFUL;
    get(current).play();
  }
  if (current != currentPlaying) {
    if (get(currentPlaying).getVolume() == 0) {
      get(currentPlaying).stop();
      currentPlaying = current;
      get(currentPlaying).setVolume(100);
      get(currentPlaying).play();
    } else
      get(currentPlaying).setVolume(max(0.0f, get(currentPlaying).getVolume() - volumeDec));
  }
}

[Nexus]

Yes, don't use global variables. They lead to problems with SFML globals, and it's a good idea to avoid them in general. In the very most cases, you can find a better design without global or static variables -- no, not singletons.

[miki151]

Note that sf::Music itself is not a global variable, it's on the heap.

[Laurent]

Don't call exit(0). It interacts very badly with C++ destructors. You should never have to call it in a well-designed program.

[miki151]

Ok I switched to return instead of exit() and it didn't help. Any other ideas?

[Laurent]

You should provide a complete and minimal example that reproduces your problem.

And what's your OS?

[binary1248]

From what I can tell, your Jukebox object is declared as a global variable (you even declare it extern in your header, so you can access it from other translation units?). Because it contains a unique_ptr to multiple sf::Music objects, they will be destroyed only when the Jukebox itself is destroyed, which will occur when the application performs deinitialization after main() has returned. Because SFML relies on an internal static AudioDevice, and that device might be destroyed before your sf::Music objects, the sf::Music objects won't be able to clean up after themselves properly, which is what you are seeing.

This could be prevented by SFML, by introducing an AlResource class in analogy to GlResource and reference count... Maybe for the next release .

But as a general rule of thumb, and the simpler solution to this situation: anything that is owned by a global variable should be considered global as well, because it will almost always have the same lifetime. sf::Music is owned by the Jukebox through the unique_ptr, so the same applies here. Make sure they are destroyed before main() returns and the problem should solve itself.

[miki151]

It worked, thanks!