Access Violation Error in Allegro 5 audio init

[Simon]

Okay, cool, thanks for confirming. Then this partial fix will go into 0.9.9.

-- Simon

[ccexplore]

Cannot repro on Linux.

It's likely an issue in one of the Windows-specific Allegro audio drivers.  For example, I skimmed through the DirectSound driver's code and there are a fair number of "FIXME" comments, including some in the _dsound_open function that I think is used during the initial driver loading.  Not exactly a vote of confidence on the quality of the code, and could well be related to the odd behavior observed with the driver not loading under certain conditions on certain versions of Windows, if there are no other Allegro audio drivers available on Windows (not sure) to fall back to.

There is one particular (and obvious) line that is suspect, and kind of makes me wonder if delaying the loading of the Allegro audio driver may help minimize this problem's rate of occurrence, specifically if there's some way to make sure the Lix window is already displayed before trying to load audio driver.

[Simon]

Lix initialized the audio before creating the window.

I've pushed a fix to unstable/master that lazily initializes the A5 audio driver. Since the main menu wants to print whether initialization is successful, audio gets now initialized on entering main menu. The display exists by then.

I've built this for Windows and attached the exe here, too. Would love feedback from Forestidia or Arty on this.

• Does it fix the crash?
  
• Do you have audio every time? The main menu should print a warning in the lower-left corner otherwise.
  
• What happens when you change resolution or display mode during program run? Does audio still work after the resolution change? (The sound driver persists throughout app's run once initialized.)
  

-- Simon

[Forestidia86]

• Does it fix the crash and give you audio every time you run the app from the quickstart bar?
  
• What happens when you change resolution or display mode during program run -- audio persists from the old window.
  

From my side it seems to look good. I haven't gotten the error even with the reliable seeming method.
But maybe Arty should test nevertheless, since he had it consistent.
Thanks, ccexplore.

Resolution change and display mode change seems to work fine for me. Music just runs on.

[Simon]

From my side it seems to look good. I haven't gotten the error even with the reliable seeming method.
But maybe Arty should test nevertheless, since he had it consistent.
Thanks, ccexplore.

Resolution change and display mode change seems to work fine for me. Music just runs on.

Okay, perfect, thanks for the quick feedback! I've sent a PM to Arty, waiting for feedback now. This will be wonderful information for the Allegro 5 issue on github, too.

Excellent hunch from ccexplore to reorder the initializations. Thanks a ton, that skips a lot of agonizing reduction. It should be irrelevant whether the display or sound driver exists first, but apparently it makes a difference. It makes sense that the big restructuring for #222 introduced this.

ccx, was it this part of the A5 code?

Code Select Expand

/* FIXME: The window specified here is probably very wrong. NULL won't work either. */
hr = device->SetCooperativeLevel(GetForegroundWindow(), DSSCL_PRIORITY);

-- Simon

[Simon]

In case Forestidia would still like to build again and produce an allegro.log file (I don't think we need it anymore, though): I've tried once again to pack debugging DLLs and LIBs, see attachment. Maybe I made a mistake earlier.

I doubt this is useful anymore because we're on a good track. I attached this merely for completeness.

-- Simon

[Colorful Arty]

Yep, running the lazy audio .exe file boots up the game just fine, regardless of whether it is done from the taskbar or not. The regular .exe still won't run from the taskbar though.

[Simon]

Cool! Thanks everybody for the debugging help. I'll use this lazy initialization in 0.9.9 then, and will report our findings upstream.

-- Simon

[Forestidia86]

In case Forestidia would still like to build again and produce an allegro.log file (I don't think we need it anymore, though): I've tried once again to pack debugging DLLs and LIBs, see attachment. Maybe I made a mistake earlier.

I doubt this is useful anymore because we're on a good track. I attached this merely for completeness.

I've tried it but I needed some DLLs that are contained in a MinGW-distribution on top of that (e.g. libwinpthread-1.dll). With adding them it ran and gave me the allegro.log. (The crash window message comes from Microsoft Visual C++ Runtime Library.)
The error seems exactly there where ccexplore suspected.

Log for taskbar crash (Win 7) (I've shortened the path for the Lix root directory.):
stdio    D         file_stdio.c:109  file_stdio_fopen                 [   0.00000] opening C:\...\LixD-master\bin\allegro5.cfg r
system   W            wsystem.c:792  _al_win_safe_load_library        [   0.00000] PathFindOnPath failed to find shcore.dll
system   D            wsystem.c:788  _al_win_safe_load_library        [   0.00000] PathFindOnPath found: C:\Windows\system32\user32.dll
system   D            wsystem.c:699  load_library_at_path             [   0.00000] Calling LoadLibrary C:\Windows\system32\user32.dll
system   I            wsystem.c:702  load_library_at_path             [   0.00000] Loaded C:\Windows\system32\user32.dll
system   I             system.c:263  al_install_system                [   0.00000] Allegro version: 5.2.3
dtor     D               dtor.c:196  _al_register_destructor          [   0.00014] added dtor for timer 000214E8, func 696363E1
dtor     D               dtor.c:196  _al_register_destructor          [   0.00697] added dtor for queue 0002FB00, func 69625C77
dtor     D               dtor.c:196  _al_register_destructor          [   0.00704] added dtor for queue 0002FB80, func 69625C77
audio-dsound I           dsound.cpp:255  _dsound_open                     [   0.00707] Starting DirectSound...
audio-dsound D           dsound.cpp:264  _dsound_open                     [   0.02727] DirectSoundCreate8 succeeded
audio-dsound E           dsound.cpp:269  _dsound_open                     [   0.02733] SetCooperativeLevel failed: DSERR_INVALIDPARAM
audio    E              audio.c:23   _al_set_error                    [   0.02734] No audio driver can be used. (error code: 1)

[Forestidia86]

Following Nordic Bots coverage I've fiddled around as well and yeah I can get the error in Win 7 with lix-lazy-audio.exe as well but that's really forced. Nothing compared to the normal use through the taskbar which seems to be basically fine now. It's just an inherent bug in Allegro 5 that can always hit.

Edit: To be clear with crash I've meant error not really crash, I've just meant the error message in Lix, sorry.

[Forestidia86]

Just an unnecessary addition:

I've never tried to double initialize with the task bar. I used two executables or link and exe and pressed Enter on one and quickly double clicked on the other afterwards. (Maybe like here said it's just that double clicking focuses the window where you double click but I don't know.)

If you click on an active taskbar icon which has a window in the foreground then it usually minimizes rather than activating multiple times (at least as far as I encountered). (If I fast click while initializing I usually don't get the minimizing, maybe because the window has to initialize or something like that. It actually can behave a bit odd in this case.) But in the end it just seems like another way to force it.
You can force the error with double clicking on the taskbar icon with precise timing. The opening of the window looks in most cases regular. (If I'm a tiny bit off I think then I sometimes get the small menu I usually get when I right click on the icon without right clicking but I don't get the error usually in this case.)

Edit: I can force it as well when pressing Enter on lix.exe and then starting quickly another program from taskbar. Mere clicking on the taskbar itself (without launching a program) works as well but is much more fiddly.

[Simon]

Thanks for the good tests! This is all in line with the theory that the reordered initialization in Lix helps, especially for running one instance, but remains a workaround around the A5 issue in the end.

-- Simon

[Simon]

I've mentioned Forestidia and ccexplore for their excellent debugging.

-- Simon

[Simon]

SiegeLord has a potential fix, but needs testing on Windows.

Forestidia, do you still have your setup with the debugging DLLs?

• Replace your allegro_audio-debug-5.2.dll with the one from the attached archive.
  
• Build the Lix 0.9.8 source against those DLLs. (I assume your debugging LIBs will work for this.)
  
• Try to repro the crash (run Lix from the quicklaunch bar, or run several instances of Lix at the same time). If the bug still manifests with this hack-fixed audio DLL, Lix should crash. If the fix works, Lix should initialize audio and not crash.
  
• Attach allegro.log

Others:

• Make a test copy of your entire Lix directory, any 0.9.x should be OK.
  
• Extract the attached archive into the copied Lix directory.
  
• Try to repro the crash: Run Lix 0.9.8 (executable included in the attached archive) from the quicklaunch bar, or run several instances of Lix at the same time. If the bug still manifests with this hack-fixed audio DLL, Lix should crash. If the fix works, Lix should initialize audio and not crash.
  
• Tell me whether you could make Lix crash.

-- Simon

[Forestidia86]

My short tests couldn't produce a crash (what doesn't exclude that there can be still problems).
Attached an allegro.log with the new DLLs (Win 7).