Access Violation Error in Allegro 5 audio init

[ccexplore]

Reason: You crash in al_create_voice, which, according to the call stack, is called from al_stricmp. But al_stricmp is a side-effect-free function to compare text strings, it definitely won't call al_create_voice, a sound routine. Since the call stack looks like this nonetheless, I suppose corrupt memory. Maybe Allegro was badly loaded this time. Maybe you ran out of free RAM. Maybe the RAM hardware has become faulty, but that is rare. Maybe there is a weird bug in Allegro or its D bindings. Definitely ignore and only investigate if it happens more often.

It's more likely the callstack information displayed is not completely accurate.  This can happen particularly with release builds since an accurate callstack requires knowing the memory addresses in the DLL/EXE of every public and private function (ie. a name <-> address mapping).  This is extra data that either has to be carried in the DLL, or be provided in some supplementary file.  Without such information, the only related information left are the addresses of functions exported by the DLL/EXE to be called by external callers (eg. entry-point functions like "main", and the functions the DLL provided to external callers).  The callstack may show al_stricmp only because it happens to be the closest known address in the DLL to the numeric address value observed in the callstack.  It may actually be some private audio function in Allegro that cannot be mapped to a name at runtime, since there is no information about that function name and address.

Hopefully a debug build of Allegro may be more complete wrt to addresses for callstack.

I'm also wondering if a web search may find more information, I suspect the underlying issue probably isn't that uncommon, so even a search for the symbols called out in the callstack (al_stricmp, al_create_voice, etc.) may yield useful hits despite inaccuracies, simply because someone else may have reported or asked about a very similar callstack in their own programs as well.

[Simon]

Simon, I'm getting constantly errors that I'm missing DLLs. It started with that allegro-debug-5.2.dll is missing. Can you say which of the countless instances you used (static or dynamic?, i686 or x86_64?, 5.2.3.0 or ~.1?). Do I need MingW?

After several hours of testing around I don't think I can build it without help. I actually don't even know when I successfully build such a build against debugging libraries.

New try: Debugging DLLs/LIBs in reply #35's attachment. I didn't test anything earlier -- I made the archive, uploaded, and went to bed.

For both archives, I used allegro-i686-w64-mingw32-gcc-7.2.0-posix-dwarf-dynamic-5.2.3.1.zip.

I can probably rename the .libs as I want; at least when assuming the crazy workstyle that replaces release libs with debugging libs in the global compiler directory. But I shouldn't have renamed the DLLs. The DLLs should be called exactly as the your DLL-not-found error wants them.

If the DLLs are not found at runtime, even though you put correctly-named DLLs into the DMD dir, then put the DLLs in the game directory instead.

The callstack may show al_stricmp only because it happens to be the closest known address in the DLL to the numeric address value observed in the callstack.  It may actually be some private audio function in Allegro that cannot be mapped to a name at runtime, since there is no information about that function name and address.

This is excellent insight. Thanks!

I didn't suspect this, I thought memory corruption was the only explanation. But in these January 2018 crash reports, the exact same message reproduces too well, it's probably not memory corruption.

At least I'm happy that I came to the same conclusion that A5 debugging builds might help.

No results for quick web search for crashes in al_create_voice. Tried some variation, but whenever the search becomes too detailed, it finds only this very thread, plus maybe raw Allegro source files. <_<;

-- Simon

[Forestidia86]

I think I even tried something like that and it builds and runs but I can't find any log when I get the crash and the error message stays basically the same. (But it looks like I made a debug Allegro build. Not really I just misunderstood something.) Where to find the extra information?

[Simon]

Oh, okay. If the crash log or dialog box remains the same like this, then I don't have good advice anymore. :-/

In my source code, I log the error that audio cannot be installed, but still continue happily after.

Speculation {
After I notice that Allegro 5 fails to install audio, it is a bug in Lix to blissfully call any more Allegro 5 audio functions. The crash happens because I do. The real issue is what prevents Allegro 5 from installing audio in the first place. The problem happens before the crash.
}

This means that I should build a small example program that initializes audio. This example should then be run under the crashy conditions, to see if installation of audio fails.

-- Simon

[Simon]

When you ran against debugging libs, did Lix produce allegro.log? Post that if it did.

-- Simon

[Forestidia86]

When you ran against debugging libs, did Lix produce allegro.log? Post that if it did.

That's actually the problem that I don't see any. That's why I'm not fully sure if I run against debug libs.
I had an allegro.log as I tried crazy things like putting your dlls with and without -debug in bin but then I think it needed dlls that come with MinGW and it crashed when started with a message from a c++-application.

The error message for the task bar crash always mentions places in allegro code: system.d(45) and system.d(62). Doesn't that mean anything?

Edit: I'm getting more and more the impression that I didn't manage to link against debugging libraries. The only setting where I seemed to have done it, the game refused to run completely (but got allegro.log there).

[Simon]

system.d(45) and system.d(62). Doesn't that mean anything?

This is inside a wrapper function that runs all my Allegro-5-calling usercode. It merely means that I run everything through al_run_main, as is required by the D bindings. This is not specific to the sound because nearly my entire program comes after that.

I assume this appears at the bottom of the call stack, wherease al_stricmp, al_create_voice and friends appear near the top of the call stack.

Based on my speculation from earlier, I'll try to fix the crash in the next version and continue without sound, not calling any Allegro 5 sound functions that look crashing.

-- Simon

[Simon]

It's an Allegro issue, most likely. I found exact same bug report on Allegro's forums: Running game from quicklaunch bar fails al_install_audio on Windows 7.

https://www.allegro.cc/forums/thread/616302

-- Simon

[Forestidia86]

Can it be related to the taskbar issue concerning software fullscreen on Win 7? On the Win 8.1 laptop I don't have the fullscreen taskbar issue and the taskbar crash is rare and hard to get. Although Arty has Win 8.0 and consistent crash.

What bugs me is that I don't get an allegro.log. I don't know why.

But nevertheless before fix #222 the crash doesn't seem so likely. Maybe ask Arty if he has the issue with an Lix instance earlier than 0.9.6.

[Simon]

Can it be related to the taskbar issue concerning software fullscreen on Win 7? On the Win 8.1 laptop I don't have the fullscreen taskbar issue and the taskbar crash is rare and hard to get. Although Arty has Win 8.0 and consistent crash.

I don't remember the taskbar issue re fullscreen. <_<;; I suppose it wasn't #262 (Fullscreen, can't switch to other windows, Windows)?

What bugs me is that I don't get an allegro.log. I don't know why.

There's always a chance that I made a mistake in preparing the dll/lib archives. If you'd really like to try again: Get an A5 binary release and generate the lib files with implib. I don't remember how to write a shell loop in Windows batch.

But nevertheless before fix #222 the crash doesn't seem so likely. Maybe ask Arty if he has the issue with an Lix instance earlier than 0.9.6.

He never complained before 0.9.8, but I can ask again to be sure.

-- Simon

[Forestidia86]

I don't remember the taskbar issue re fullscreen. <_<;; I suppose it wasn't #262 (Fullscreen, can't switch to other windows, Windows)?

I actually meant this issue. I have weird taskbar problems there, that I can't make other windows appear (on old Win 7 laptop) if I have software fullscreen and click on the taskbar after using the Win key .

Description:

Using the Win key: Clicking on other tabs on the Taskbar doesn't seem to produce visible/overlapping windows (at least for me). But if you use the Start menu as is activated by the Win key (without clicking on the Taskbar beforehand) then it can be possible to produce visible/overlapping windows. If you have produced such a window, even clicking on the Taskbar seems to work in this respect again.

(You can always start other programs (and see them pop up in the Taskbar as tabs), but their windows are not always visible/are sometimes in the background as explained above.)
[...]
The general rule seems to be: Using keys in the first place to get to other windows brings you in a state where you can produce overlapping windows generally (even by clicking on the Taskbar) but using in first place the mouse to click on the Taskbar generally denies you such a state.

But maybe that's something else taskbar related since I think it's been there longer.

[Simon]

I've reported this against Allegro 5, linking back to this thread and to the 2016 thread on allegro.cc.

These days, I'll have another go at building debugging libraries and giving Forestidia and Arty a small self-contained example program.

-- Simon

[Forestidia86]

Simon, have you tried to reproduce the crash with double initialization (opening two instances of Lix at the same time or a bit delayed)?
I've tried to catch something with a batch file and redirecting arrows (via double initialization), but it only logged the Lix crash window message. Interestingly sometimes it just closed without showing the error message window then but maybe that has to do with using a batch file with redirecting arrows.

[Simon]

Cannot repro on Linux. This script opens 3 instances of Windows Lix through Wine and 3 instances of Linux version, all within 4 seconds. I get no problems at all, and all 6 instances play music at the same time in the main menu.

Spoiler

Code Select Expand

#!/bin/sh

wine dub build
dub build

wine bin/lix.exe &
wine bin/lix.exe &
wine bin/lix.exe &

bin/lix &
bin/lix &
bin/lix &

I fixed the crash in unstable/master. Now, you should hear no audio and get an error in the main menu, but can still continue playing.

-- Simon

[Forestidia86]

I fixed the crash in unstable/master. Now, you should hear no audio and get an error in the main menu, but can still continue playing.

Yeah, that's exactly what is happening.