OgreOggSound crashes when exiting and threading is enabled about ogre-audiovideo

[paroj]

are you using the code from your PR? If so, there are some non _WQ lock variants, which are noops. This might lead to wrong method call order i.e. use of a deleted object.

[sercero]

No, I am using code from another PR which I didn't submit (option 1).

I will see what happens with the code from the PR you saw and check the non _WQ lock variants.

Thanks!

[sercero]

Hey @paroj, I replaced all the OGRE_LOCK_MUTEX_NAMED for OGRE_WQ_LOCK_MUTEX_NAMED.

There is no change, in fact I see this in OgreThreadDefines.h:

#define OGRE_LOCK_MUTEX_NAMED(mutexName, lockName) OGRE_WQ_LOCK_MUTEX_NAMED(mutexName, lockName)

And those are all the locks I'm using.

There seems to be a problem with the usage of the replacements in OgreThreadDefines.h, because when using the code from the PR#14 the crash is even worse.

So, I have two branches:

• std_thread: just adds std::thread as a third option to POCO and boost, the changes are minimal
• std_thread2: that is the branch from PR#14 that you know

When using branch std_thread the application crashes on exit, but only when using the debugger to step through the code. If using release or debug normally the crash does not happen (there is still something wrong) but the user won't notice.

When using branch std_thread2 the crash happens always and it is much more visible.

If you want I can submit another PR with branch std_thread so you can check that out.

Also let me know if you think that this is too much work for minimal gain 😭

[paroj]

There is no change, in fact I see this in OgreThreadDefines.h:

this is only used if OGRE_THREAD_SUPPORT != 3, but 3 is the default (only workqueue syncronised).

When using branch std_thread2 the crash happens always and it is much more visible.

when it comes to threading a reproducible crash is better than a crash that only happens sometimes. With a debugger attached, the application execution is slowed down, so that crash might also happen in release mode on a slower computer.

I will try to take a look at this soon.

[sercero]

when it comes to threading a reproducible crash is better than a crash that only happens sometimes. With a debugger attached, the application execution is slowed down, so that crash might also happen in release mode on a slower computer.

When I said always what I meant was that it happened both in release and debug version with and without the debugger attached, it is a much harder crash.

The other crash (the one referenced in this thread) is also very consistent and happens always when exiting and joining the other thread but it happens only when you are running the debug version inside a debugger which is a situation that a user is very unlikely to come up with.

If you want I can submit another patch request from the other branch so you can see what I'm talking about.

Anyway, I really apreciate you looking into this because this problem goes over my head.

Thanks!

[sercero]

It seems that the problem was related to OpenAL Soft for Windows in some way, I am now using the latest version 1.21.1 and the problem is gone.

[paroj]

also giving you maintainer access, as you know the code better than me by now