-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixxx x64 Windows crashes on startup if FlexASIO 1.4 or JACK are installed. #10081
Comments
Commented by: siana-gearz 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. I don't believe you should workaround by dropping address randomisation. After all, a malicious audio or coverart file is always a possibility. |
Commented by: kolvis 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. |
Same here, mixxx 2.3.3 on x64 windows is crashing right after FlexASIO 1.9 install |
Why do you need FlexASIO in the first place?
compared to this
But anyway, you can help debugging by creating a backtrace according to this guide: |
Did you try the SB3 with 48 kHz? |
The error originates from the default path and can be probably improved: mixxx/src/soundio/soundmanager.cpp Line 537 in e28e041
Does mixxx.log contain more infos? |
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 |
Thank you for the backtrace. It discovers that we have a concurrent Initialization of PortAudio in SoundManager::queryDevicesPortaudio() I will prepare a branch with more debug output. |
It turns out to be PA_init() so there is no chance for a workaround without changing Portaudio. |
The upstream bug is filed. |
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. |
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. |
@siana Could you test if the issue still occurs with the following build (from #11451) : https://github.com/mixxxdj/mixxx/actions/runs/4637080755 |
Fixed since #11451 |
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 |
Reported by: siana-gearz
Date: 2020-08-11T00:14:04Z
Status: New
Importance: Undecided
Launchpad Issue: lp1891098
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.
The text was updated successfully, but these errors were encountered: