sf::Sound and sf::SoundBuffer declaration order crash

[myroidtc]

I'm not sure if this is on my end or not. I'm using static-linked SFML 2.2, VC 2012, 64-bit Windows.

This works:

Code: [Select]

int main() {
   sf::SoundBuffer buffer;
   sf::Sound sound;
   buffer.loadFromFile("foo.wav");
   sound.setBuffer(buffer);
   sound.play();
   return 0;
}

But this doesn't:

Code: [Select]

int main() {
   sf::Sound sound;
   sf::SoundBuffer buffer;
   buffer.loadFromFile("foo.wav");
   sound.setBuffer(buffer);
   sound.play();
   return 0;
}

Specifically, declaring the sf::Sound before the sf::SoundBuffer it uses causes a crash and references XTree and some iterator error. The crash happens during the SoundBuffer destructor. This is new to me in 2.2 and wasn't the case in 2.1 stable.

Is this intended behavior?

[Jesper Juhl]

I'd guess the problem is with the order the objects are destroyed in.
When you declare the soundbuffer last it will be destroyed first when leaving the scope (main), thus for a short while (and when it itself is destroyed) the sound will reference a soundbuffer that no longer exist.

[Hapax]

What Jesper said 


This has come up before. I've definitely seen it on the forum already somewhere (did you search?) so it's been a 'feature' for a while.

[Tommy22pa]

This works:

int main() {
        sf::Sound sound;
        sf::SoundBuffer buffer;
        buffer.loadFromFile("foo.wav");
        sound.setBuffer(buffer);
        sound.play();
        sound.stop();
        sound.resetBuffer();
        return 0;
}
 

 

[Jesper Juhl]

Ehh. Why not just declare the SoundBuffer first so things get destroyed in the proper order?

[Tommy22pa]

http://en.sfml-dev.org/forums/index.php?topic=17095.msg122905#msg122905

[Laurent]

How is this other thread related to the problem?

[Tommy22pa]

I hope not.

[Jesper Juhl]

Then why bring it up?

The problem is obvious; objects created in wrong order.
The simple correct fix is to create them in the proper order.