[FIXED] OpenAl crashes while unloading since 2.8.1

[Cero]

Happens with 2.8.1 aswell as the current nightly build dubbed 2.8.2

When exiting my game, at which point OpenAL will be unloaded by Slick, OpenAL makes java Crash.

Problem signature:
  Problem Event Name:	BEX
  Application Name:	javaw.exe
  Application Version:	7.0.10.8
  Application Timestamp:	4e897db7
  Fault Module Name:	OpenAL32.dll_unloaded
  Fault Module Version:	0.0.0.0
  Fault Module Timestamp:	4e894548
  Exception Offset:	172dd03f
  Exception Code:	c0000005
  Exception Data:	00000008
  OS Version:	6.1.7600.2.0.0.256.1
  Locale ID:	18441
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

[Matzon]

seeing something similar - however, its AFTER OpenAL has been destroyed and at the end of all java code.
I cannot make it happen in eclipse, so hard to debug.

*** DESTROY - context ***
DLL_THREAD_DETACH - start
DLL_THREAD_DETACH - end
*** DESTROY - device ***
[Loaded java.util.HashMap$Values from C:\Program Files\Java\jre6\lib\rt.jar]
[Loaded java.util.HashMap$ValueIterator from C:\Program Files\Java\jre6\lib\rt.jar]
*** DESTROY reset AL10 ***
[Dynamic-linking native method org.lwjgl.openal.AL.resetNativeStubs ... JNI]
*** DESTROY reset AL11 ***
*** DESTROY reset ALC10 ***
*** DESTROY reset ALC11 ***
*** DESTROY reset EFX10 ***
*** DESTROY nDestroy ***
[Dynamic-linking native method org.lwjgl.openal.AL.nDestroy ... JNI]
extal_UnloadLibrary '41e0000'
DLL_PROCESS_DETACH - start
DLL_PROCESS_DETACH - end
extal_UnloadLibrary DONE (1)
JAVA DONE!!!
[Loaded java.lang.Shutdown from C:\Program Files\Java\jre6\lib\rt.jar]
[Loaded java.lang.Shutdown$Lock from C:\Program Files\Java\jre6\lib\rt.jar]
[Dynamic-linking native method java.lang.Shutdown.halt0 ... JNI]

[Matzon]

I've debugged it all the way through both LWJGL and OpenAL-Soft dlls. I cannot find a reason for why this is happening - and I certainly have no idea where OpenAL32_unloaded comes from, but then again I dont get that on my end - just a generic stopped working.

[Cero]

seeing something similar - however, its AFTER OpenAL has been destroyed and at the end of all java code.

Yeah could be, I still get the line

AL lib: FreeContext: (20230D38) Deleting 64 Source(s)

and I guess it crashes after that, as I get all my system outs

Not sure if I can verbose it better somehow, to see whats going on. But I'm using OpenAL purely through Slick anyway, nothing special.

[Cero]

It's Win 7 64 bit

but everything I use is 32 bit: eclipse, java, lwjgl, everything - because I found java 64 to be unstable, and I dont need it

so it's not a 32bit / 64bit issue whatever somehow suggested

[Matzon]

I am on it ... seems to be an OpenAL-Soft issue. Tricky to fix, but basically the mmdevapi backend is being de-initialized from the DllMain entry point, which is causing the mmdevapi's call to CoUninitialize to crash, as per:

Because there is no way to control the order in which in-process servers are loaded or unloaded, do not call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function.

Simple fix is to not include mmdevapi, but since its basically required from vista and onwards, we need a better fix. Not sure when tho...

[princec]

Probably going to have to hack on the OpenAL source itself Maybe a mutex will fix what sounds like a race condition.

Cas

[Matzon]

Probably going to have to hack on the OpenAL source itself Maybe a mutex will fix what sounds like a race condition.

Cas

Nah, its a bit more tricky than that. The design is based on deinitlialization on destructore basically, which isn't allowed - for this particular backend.

So AL needs to get an explicit destroy thingy which isn't in the specs.

or something along the lines... I'll find out today I hope

[Faust]

Hi,

i just found this topic when searching for problems with version 2.8.1 and AL.destory().
I want to add that calling AL.destroy() causes the error on a Vista 64bit System right out of eclipse (indigo jre1.6.29 64bit), but only shows the generic "has stopped working" message. In fact, stepping through the source code is not possible after AL.destory() has been called since java stoped working some time after the call but not at the end of all threads.
In addition the same source code runs and shuts down error-less on a 32bit Windows XP.

I hope this information might help in any way.

[Ckadge]

Hello everyone,
I have exactly the same problem. Java crashes when I destroy AL.
For some reason it takes a while before Java crashes, because when I shutdown my program, and AL is being destroyed, the program can still shutdown properly.
Another weird thing is, Java only crashes when I have loaded a texture in my program and I destroy AL. I don't think this has anything to do with sound.

What are the consequences when I do not destroy AL? Testing has become a but annoying because of this.
As a quick fix, I'll just disable the whole sound manager, but I'd like to see this solved!

I found this problem a few days ago. I'm glad to see that there's already someone on it!

edit: In addition, I'm using a Vista 32-bit system, running Java 1.6.

[Matzon]

should be fixed as of r3686
Please grab dll from svn or wait for next 2.8.2 build.

Just a small FYI: The issue happens on Vista and Windows 7 - it's caused by a late call to CoUninitialize() of the mmdevapi backend. It doesn't happen all the time, but very often - especially after the first run.
It happens on both 32 and 64 bit.

I have updated all OpenAL soft versions to latest, which contains a fix for this issue.

[Ckadge]

Seems to work! Thank you so much!

[Cero]

Yeah works!

[jim_oflaherty_jr]

Hi,

Thank your for this thread. I have been tearing my hair out trying to figure out what I was doing wrong causing this error. I was on 2.8.1.

Summary: After installing 2.8.2, be sure to shut down and restart Eclipse to "unload" the old 2.8.1 dlls

Details:
For others that might follow, I discovered an additional little fun treat. It appears that for as long as Eclipse is up, it somehow caches the .dlls. So, when I dl'ed 2.8.2 and went and changed the referenced libraries (without having shutdown Eclipse) and did a "Clean..." to force a full rebuild, I ran my game and it still popped up the same issue at shutdown. After verifying everything was properly configured in Eclipse to point to the new 2.8.2 version (including renaming the 2.8.1 folders), I tried my program again and it still hit the same shutdown error for the OpenAl dll. On a hunch, I shutdown Eclipse, restarted it and immediately ran my program and shut it down. And the error was gone. I then cycled through it several times and no error appeared. Hope this helps any future followers...

[Cero]

Actually I'm getting this error again lately.