Mixxx x64 Windows crashes on startup if FlexASIO 1.4 or JACK are installed.

[mixxxbot]

Reported by: siana-gearz
Date: 2020-08-11T00:14:04Z
Status: New
Importance: Undecided
Launchpad Issue: lp1891098

---

Mixxx 2.2.4 official release Windows 64-bit, running on Windows 10 64-bit release 20.04. The crash occurs apparently before log file is written to (it's not existing or empty), but after the window is created. %LOCALAPPDATA%\Mixxx had been cleared prior to running.

Reproduces against the last Windows release JACK v1.9.11-x64
Reproduces against FlexASIO 1.4; however FlexASIO 1.5 no longer reproduces.

I narrowed down the third party software complicit in the crash using a debugger, didn't investigate the mechanism of crash in depth, but it seems to be somewhere in PortAudio chain loading the various ASIO drivers, and JACK comes with an ASIO application adapter.

Release notes for FlexASIO 1.5 make it known that it fixes an issue with PortAudio based applications. I assume JACK might be suffering a similar issue, maybe it's trying to load a DLL which is nominally already in the process address space because you use the same library, specifically PortAudio itself, but is not a compatible version. It's also of note that the last JACK for Windows release has been a long while ago, several years.

Potentially, no mitigation on your end is needed or desired, JACK being a systemwide utility needs to fix it on their end, else there is potentially a larger and growing class of applications that can be affected, however you may want to document the incompatibilities somewhere visibly, because it may result in enduser frustration, either them dropping your software from the get go or being very frustrated not having experience to determine the cause.

I also find the logging a bit questionable that it doesn't even get to spit out that it's starting to load PortAudio, which is unfortunate if PortAudio is prone to crashes caused by third party systemwide software. If verbose logging while loading various drivers is possible, it would be ideal.

I'll also get in touch with JACK and see what i can do there, maybe i can temporarily take up Windows release maintenance.

[mixxxbot]

Commented by: siana-gearz
Date: 2020-08-11T02:02:52Z

---

I have filed a bug against JACK here jackaudio/jack2#623

A related bug has been known to JACK for 3 years and has not been fixed. There is some kind of addressing issue or cast truncation going on, causing JACK to fail on 64-bit Windows host applications with address layout randomisation. It affects several known applications, including Traktor 3 and Radium.
jackaudio/jack2#275

I don't believe you should workaround by dropping address randomisation. After all, a malicious audio or coverart file is always a possibility.

[mixxxbot]

Commented by: kolvis
Date: 2022-07-20T03:49:40Z

---

I don't know if it's the same issue or not, but I'm seeing what appears to be the same/a similar issue when using the current stable version of Mixxx (2.3.3) with FlexASIO installed. After uninstalling FlexASIO Mixxx suddenly has no qualms starting. This is with FlexASIO version 1.9, by the way. I'm not sure whether I should comment here or make a separate bug report, but here we are.

[feczo]

Same here, mixxx 2.3.3 on x64 windows is crashing right after FlexASIO 1.9 install

[daschuer]

Why do you need FlexASIO in the first place?
In case of Mixxx you build this stack:

• Device Diver
• WDM-KS
• Portaudio
• FlexASIO
• ASIO
• Portaudio
• Mixxx

compared to this

• Device Diver
• WDM-KS
• Portaudio
• Mixxx

But anyway, you can help debugging by creating a backtrace according to this guide:
https://github.com/mixxxdj/mixxx/wiki/Creating-Backtraces
And post it here.

[feczo]

Unfortunately I had to work around the WDM-KS not being usable as per screenshot, so maybe I have to go back trying to troubleshoot that more...

[ronso0]

Did you try the SB3 with 48 kHz?

[daschuer]

The error originates from the default path and can be probably improved:

mixxx/src/soundio/soundmanager.cpp

Line 537 in e28e041

default:

Does mixxx.log contain more infos?

[murl-digital]

Why do you need FlexASIO in the first place?

Speaking from experience, screen sharing. ASIO in general is a pain to deal with if you want to share audio from an application in any way. Not only do I use it to share what I'm working on in a discord call, but it's a useful tool if you're doing a URLfest for example. Also attached is a trace I created with the latest 2.4 alpha.

log-Mon Jan 16 12-01-19 2023.txt

mixxx.log is empty

[daschuer]

Thank you for the backtrace. It discovers that we have a concurrent Initialization of PortAudio in SoundManager::queryDevicesPortaudio()
It calls static Portaudio function calling CFlexASIO::init leading to a recursive loop that ends with a STATUS_STACK_BUFFER_OVERRUN crash.
I can imagine that there is a way to skip CFlexASIO::init to avoid this loop.

I will prepare a branch with more debug output.

[daschuer]

It turns out to be PA_init() so there is no chance for a workaround without changing Portaudio.

[daschuer]

The upstream bug is filed.
We may consider to use a patched version of Portaudio to fix this bug.

[dechamps]

mixxx 2.3.3 on x64 windows is crashing right after FlexASIO 1.9 install

It calls static Portaudio function calling CFlexASIO::init leading to a recursive loop

I find this surprising given this exact failure mode was found and fixed in FlexASIO long ago - see dechamps/FlexASIO#47. As far as I know the fix is robust so I am quite surprised to see this problem reappear. I filed dechamps/FlexASIO#182 to track this on the FlexASIO side.

[dechamps]

I was able to confirm in dechamps/FlexASIO#182 that there is indeed a regression in FlexASIO that reintroduces this problem starting from FlexASIO 1.8 - sorry about that. I will make sure it's fixed in the next FlexASIO version. In the meantime, the best I can offer is to uninstall FlexASIO or to downgrade it to FlexASIO 1.7a.

[JoergAtGithub]

@siana Could you test if the issue still occurs with the following build (from #11451) : https://github.com/mixxxdj/mixxx/actions/runs/4637080755

[daschuer]

Fixed since #11451

[dechamps]

FYI, the original root cause of this issue, dechamps/FlexASIO#182, is fixed in FlexASIO 1.10, by ensuring that the Windows DLL loader will not share FlexASIO's portaudio.dll with any other part of the host application. (I apologize for taking this long to release the fix…)