libjack64.dll crashes on application startup

[rehans]

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]

On Wed, Jul 12, 2017 at 4:00 PM, René Hansen ***@***.***> wrote: 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?

Which compiler? Do you have backtrace? If you don't bother finding out how to get backtrace, perhaps you can add various debug printings to the program: ``` #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; } ```

[kmatheussen]

#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]

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]

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]

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]

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

[EvanBalster]

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]

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]

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]

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]

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]

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]

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

[jcelerier]

The problem can be hit fairly simply : #332

[EvanBalster]

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]

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

[ReinholdH]

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]

If I haven't misunderstood the problem, I think it's important to point out that it is not jack itself that's causing this, it's the ASIO jack bridge. Just unregister that asio driver, the same way you had to register it (regsvr32 command or something like that), and things should work again.

…

On Wed, Sep 23, 2020 at 9:45 AM ReinholdH ***@***.***> wrote: 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. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIX3J3647LEH27ZTEAAJYTSHGRTFANCNFSM4DSWWCQA> .

[jcelerier]

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]

@jcelerier what is the correct fix?

[kmatheussen]

Sorry, I've probably misunderstood. I guess jack needs to be recompiled with latest portaudio, and perhaps also not dynamically compiled in? In addition, this problem in portaudio can cause jack to crash as well: https://listserv.cuit.columbia.edu/scripts/wa.exe?A2=PORTAUDIO;7120129e.2009B&S= (which can also be solved by not including the WDMKS driver in portaudio) On Wed, Sep 23, 2020 at 10:09 AM Kjetil Matheussen <[email protected]> wrote:

…

If I haven't misunderstood the problem, I think it's important to point out that it is not jack itself that's causing this, it's the ASIO jack bridge. Just unregister that asio driver, the same way you had to register it (regsvr32 command or something like that), and things should work again. On Wed, Sep 23, 2020 at 9:45 AM ReinholdH ***@***.***> wrote: > 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. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <#275 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AAIX3J3647LEH27ZTEAAJYTSHGRTFANCNFSM4DSWWCQA> > . >

[jcelerier]

@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]

@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]

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

[gsuberland]

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]

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]

@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]

@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.