Skip to content
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

libjack64.dll crashes on application startup #275

Open
rehans opened this issue Jul 12, 2017 · 28 comments
Open

libjack64.dll crashes on application startup #275

rehans opened this issue Jul 12, 2017 · 28 comments
Labels
Windows Bug or feature related to using JACK on Windows

Comments

@rehans
Copy link

rehans commented Jul 12, 2017

I've built a small test application (64 bit) using simple_client.c of the jackaudio/example-clients respository. On Linux and Mac it is working like expected but on Windows 10 it crashes right after starting the application.

Exception thrown at 0x0000000069A2F26B (libjack64.dll) in Jack2SimpleClient.exe: 0xC0000005: Access violation reading location 0xFFFFFFFF95A71BEC.

It does not matter if the JACK server is running or not.

I am on Windows 10 Pro, version 10.0.15063 and I used JACK2 64 bit installer 1.9.11 from http://jackaudio.org/downloads/

Any ideas?

@kmatheussen
Copy link
Contributor

kmatheussen commented Jul 12, 2017 via email

@kmatheussen
Copy link
Contributor

#define CR_STRINGIZE_DETAIL(x) #x
#define CR_STRINGIZE(x) CR_STRINGIZE_DETAIL(x)
#define CR_FORMATEVENT(msg,...) (msg ": " __FILE__ " line " CR_STRINGIZE(__LINE__) "."__VA_ARGS__)
#define TRACK(a) do{fprintf(stderr, CR_FORMATEVENT(a));fflush(stderr);}while(0)

int main(){
 TRACK("a");
 ...
 TRACK("b");
 ...
 TRACK("c");
 return 0; 
} ```

@rehans
Copy link
Author

rehans commented Jul 12, 2017

Which compiler? Do you have backtrace?

Toolset: Visual Studio 2015 (v140)

I used the release version of libjack64.dll/libjack64.lib which gets installed. I could not find any pdb or map files within the installation. These files are needed in order to get a stacktrace (unless I manage to build the debug version, but I did not do yet). The only thing I can see is the following:

ntdll.dll!RtlRaiseStatus()
ntdll.dll!RtlDispatchException()
ntdll.dll!KiUserExceptionDispatch()
libjack64.dll!0000000069a2f26b()

If you don't bother finding out how to get backtrace, perhaps you can add various debug printings to the program:

The main function of my application does not even get entered. Therefore I cannot put debug prints.

@kmatheussen
Copy link
Contributor

If you don't bother finding out how to get backtrace, perhaps you can add various debug printings to the program:

The main function of my application does not even get entered. Therefore I cannot put debug prints.

Ah, okay. And sorry if I sounded snarky.

I know it works using mingw, but I haven't compiled a jack program with visual studio, and now it's so long time since I used visual studio that I'm not sure if I even have it anymore. Perhaps someone who has experience with mvsc and jack can comment.

Also, it would be great if you post the options you use to compile simple_client.c .

@rehans
Copy link
Author

rehans commented Jul 14, 2017

Ah, okay. And sorry if I sounded snarky.

No worries ;)

Also, it would be great if you post the options you use to compile simple_client.c .

See https://github.com/rehans/GitTest please. I've setup a very simple cmake project which I used for testing.

@kmatheussen
Copy link
Contributor

Maybe try using weakjack: https://github.com/x42/weakjack
(a couple of alternatives are also linked in the bottom of the README file)

@EvanBalster
Copy link

EvanBalster commented Jul 25, 2017

Hey all —

This is causing headaches for my users since I started rolling out 64-bit versions of my app. I've done some tracing, and posted a thread on the jack-devel list about it:

PortAudio seems to die as soon as it encounters the Jack server, with a crash originating in libjack64.dll:

Exception thrown at 0x0000000069A2F26B (libjack64.dll) in imitone.exe: 0xC0000005: Access violation reading location 0xFFFFFFFFA2C96623.

The crash occurs during COM instantiation, as the ASIO SDK is calling into CoCreateInstance -> CoGetClassObject -> DoGetClassObject, from my application's perspective. I haven't managed to trace it any further than that.

The crash occurs whether or not the JACK server is running, so it makes portaudio64/ASIO pretty much unusable. Other non-PortAudio apps don't seem to have trouble. I would be happy to help debug the issue, as it looks like it may be out of my power to fix this application-side. (I'm a PortAudio contributor, though, so I have some ability to dig around inside the lib.)

In my own repro, Jack gets instantiated after two other ASIO drivers (some defunct USB thing, and ASIO4ALL) are probed. I also have a bunch of user logs.

Within PortAudio, the trace is:

portaudio_x64.dll!AsioDriverList::asioOpenDriver(int drvID, void * * asiodrv) Line 184	C++
portaudio_x64.dll!AsioDrivers::loadDriver(char * name) Line 127	C++
portaudio_x64.dll!LoadAsioDriver(PaAsioHostApiRepresentation * asioHostApi, const char * driverName, PaAsioDriverInfo * driverInfo, void * systemSpecific) Line 961	C++
portaudio_x64.dll!InitPaDeviceInfoFromAsioDriver(PaAsioHostApiRepresentation * asioHostApi, const char * driverName, int driverIndex, PaDeviceInfo * deviceInfo, PaAsioDeviceInfo * asioDeviceInfo) Line 1037	C++
 	portaudio_x64.dll!PaAsio_Initialize(PaUtilHostApiRepresentation * * hostApi, int hostApiIndex) Line 1330	C++
portaudio_x64.dll!InitializeHostApis() Line 226	C
portaudio_x64.dll!Pa_Initialize() Line 374	C

The access violation itself looks quite a lot like a pointer getting truncated to 32 bits, or combined with a bad HINSTANCE...

@falkTX
Copy link
Member

falkTX commented Jul 26, 2017

I'm not the best person to comment on Windows specific issues, but I had a similar thing happening with my own projects.
I believe it was due to win64 calling conventions being different between MSVC and mingw.
A similar thing happened when trying to use Wine stuff in 64bit.

What I ended up doing was to load the libjack[64].dll library and getting the symbols from it, instead of linking directly to it.
Linking to jack on Windows is not a good option in my view, as most users will not have it installed.

For my own project I have the code that does the magic here https://github.com/falkTX/Carla/tree/master/source/jackbridge
(it also handles some Wine specific things, so Windows/Wine apps can call Linux APIs on Linux)

@EvanBalster
Copy link

EvanBalster commented Jul 26, 2017

In my case, I'm not linking to JACK, but interfacing via ASIO (from an MSVC x64 program). I commented here because the "symptoms" of the problem appear to be almost identical (borked pointer).

The ASIO API dynamically loads the libjack64 DLL so there's no static linkage.

@EvanBalster
Copy link

EvanBalster commented Jan 5, 2018

Has there been any development on this issue? I've been blacklisting JackRouter in my 64-bit Windows app for months now. I think my conclusion was that the issue was not in PortAudio but in JACK's ASIO implementation.

@kmatheussen
Copy link
Contributor

Hmm. If you are using Visual Studio, and don't mind using a hack as solution to the problem, it might not be much work to change JackRouter.cpp into dynamically linking in libjack, and recompile the JackRouter.dll file in Visual Studio.

@EvanBalster
Copy link

Hey, K. —

I don't ship JACK with my app. The issue affects users who have installed JACK server, and interface my app with it using the latter's ASIO driver. Are you suggesting I compile and ship an alternative version of the DLL as a workaround? It would probably be easier to integrate the JACK API and keep blacklisting JackRouter...

@jcelerier
Copy link

same issue here. Some apps are able to connect to jack through ASIO (for instance PureData and Ableton Live have no problems) though.

@jcelerier
Copy link

The problem can be hit fairly simply : #332

@EvanBalster
Copy link

Hello, I have been blacklisting JACK in my 64-bit application and providing an alternative "for JACK users" installer for my application for two and a half years now. Is this bug really still in there? IIRC it's just casting a 64-bit pointer to a 32-bit integer and back.

@ghost
Copy link

ghost commented Feb 22, 2020

There's a workaround here.
rodrigodzf/Jack-Audio-For-Unity#15 (comment)

@ReinholdH
Copy link

This discussion here was very helpful after searching for hours. In the Unity forum the post about
"Disabling the address space layout randomization feature in the linker setting fixes the crash" in VS2019.
As a new guy using Jack I was just wondering why this issue has been around for so long (3 years now). But thanks to all the comments here and in the Unity forum.

@kmatheussen
Copy link
Contributor

kmatheussen commented Sep 23, 2020 via email

@jcelerier
Copy link

jcelerier commented Sep 23, 2020

Just unregister that asio driver

it would be great if this was fixed in the JACK codebase instead (or whatever provides the bridge, but AFAIK it comes from the same installer... so the code is likely somewhere around :p), as people may have installed jack at some point in the past which set up the ASIO driver that they didn't use, and then encounter crashes much later when running various music apps.

@sletz
Copy link
Member

sletz commented Sep 23, 2020

@jcelerier what is the correct fix?

@kmatheussen
Copy link
Contributor

kmatheussen commented Sep 23, 2020 via email

@jcelerier
Copy link

@sletz given that client apps need /DYNAMICBASE:NO to be able to load the jack asio bridge without crashing, I'd assume that the issue is due to a pointer being marshalled as a 32-bit value at some point but frankly hard to know without some windbg.

@EvanBalster
Copy link

@jcelerier what is the correct fix?

@sletz given that client apps need /DYNAMICBASE:NO to be able to load the jack asio bridge without crashing, I'd assume that the issue is due to a pointer being marshalled as a 32-bit value at some point but frankly hard to know without some windbg.

Bingo. The issue involves JACK stores a 64-bit pointer in a 32-bit integer, discarding the upper 32 bits. Later on, it's converted back to a pointer. If the pointer happened to have a non-zero value in those upper 32 bits, you get a crash.

I've been blocking JackRouter's ASIO driver in 64-bit versions of my application for 4-5 years now due to this issue, but I don't believe the issue is specific to the ASIO bridge.

@dyfer
Copy link

dyfer commented Mar 8, 2021

Has this been resolved with Jack 1.9.17? It has the recompiled JackRouter.

@gsuberland
Copy link

I was seeing this with 1.9.11, manifesting itself as Tenacity crashing on startup, but after updating to 1.9.21 the issue appears to be resolved.

@EvanBalster
Copy link

Seeking confirmation. Was this finally fixed?

I'm working on an ASIO-enhancing pull request for PortAudio that currently blocks JackRouter if the pointer size is not 32 bits. It's tentatively slated for inclusion in the next release. Discussion of that PR was leaning toward including the JackRouter exclusion, due to this open issue.

@jcelerier
Copy link

jcelerier commented Jul 2, 2022

@EvanBalster I think it's worth getting that PR in portaudio anyways: I routinely encounter people who installed some versoin of JackRouter 5, 6 years ago and completely forgot about it (but then have mysterious audio crashes)

@EvanBalster
Copy link

@jcelerier If there really is a fix out now, and JackRouter provides version information, there might be some way to make PortAudio check the version of JackRouter and permit the fixed versions. So I remain interested in whether anybody can confirm this has been patched.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Windows Bug or feature related to using JACK on Windows
Projects
None yet
Development

No branches or pull requests

10 participants