[Bug] MacOS incompatibility in the JVM

[DeJayDev]

Hello!

I am a maintainer of Vatuu/discord-rpc and we're finding that whenever we load libdiscord-rpc.dylib on our test device running MacOS X El Capitan (10.11.5) we're met with an Error in LSRegisterURL: -10811.

Our research is only providing us with this link.

We think, the issue lies within the lib and not in our execution of it (however, we can be very wrong). The most "stable" version of our usage of discord-rpc is on my fork at DeJayDevelopment/discord-rpc.

Update: We're only getting this error on Mac devices.

[msciotti]

Have had some offline discussion around this. Initial thoughts are: I have no idea why this is wrong. After some googling, it seemsthat -10811 refers to LSRegisterURL trying to access something that's not marked as an application by macOS, so it's possible the test .jar is not being recognized properly as something that can be registered by the OS.

Digging continues.

[Dids]

Not sure if related, but I'm statically linking libdiscord-rpc.a (v3.3.0, latest release) and not seeing this error (this is a binary, not a .app wrapper application).

However, none of my events are firing, presence isn't updating and no errors are triggering.
The only message that gets printed out is No bundle id found, but that shouldn't be stopping it from working, at least it didn't before.

[msciotti]

@Dids I think the newest working theory here is that registration is grabbing the bundle url of the java binary, and then LSRegisterURL is getting confused.

Your issue sounds separate. Are you calling Discord_RunCallbacks()? You can also open the console of your local discord client—ctrl/shift/i or cmd/option/i—and see if you get any RPC connection events when you boot up the game.

If that doesn't work, please feel free to open a separate issue and we can debug.

[DeJayDev]

Just wanted to see if I could get some more about my specific problem.

I feel like the not only our Java library will benefit from finding a fix but as will many others. But on the same note I worry the issue lies out of simple control.

[msciotti]

I think the best fix would be to forego this method of registration altogether on macOS, and stick strictly to registered the command in json like we do for steam games. Screwing around with info.plist seems like it will open itself to more unforseen problems in the future.

[Vatuu]

@msciotti Currently, the wrapper works in a way that allows the user to decide wether or not the initialization should rely on the automatic registration or the custom one using the register methods. And it‘s the same regardless of the option, so I doubt it's a issue with the registration of paths. No unsatisfied link exceptions are thrown either, only the infamous L-something error, which means the libdiscord-rpc.dylib is indeed found and loaded.

So my best guess is, that it‘s some sort of issue with macOS permission system, since the app enables without issues, but no connection to the discord client can be established.

I've heard about two interesting keywords though, „sandboxing“ and „gatekeeping“ but I am not a macOS developer, so those are pretty much a dead end to me.

This is everything we were able to figure out so far.

[msciotti]

Well, theoretically, if we bypass this:

https://github.com/discordapp/discord-rpc/blob/master/src/discord_register_osx.m#L32

And instead make the default the RegisterCommand() function:

https://github.com/discordapp/discord-rpc/blob/master/src/discord_register_osx.m#L8

There should be no problems involving LSRegisterURL, since it won't be calling it.

I'm not saying to remove automatic registration or not, sorry. What I'm saying is to force macOS registration to always use the app_id.json method, rather than the LSRegisterURL method.

[DeJayDev]

We tested with #187 to no avail. Now we're just getting a silent failure.

[dylanh724]

EDIT: I'm going to guess I'm getting a different error now since users aren't crashing anymore. TL;DR: I had a backup file that I didn't think was being picked up, but was. More in a reply below.

---

I'm also seeing an err in the latest version -- works fine for Windows, but not for Mac (Linux doesn't seem to work, either, but haven't checked those logs yet) in Unity with dynamic files:

Receiving unhandled NULL exception
Obtained 28 stack frames.
#0  0x007fff5c28d432 in strlen
#1  0x000001021ef2ea in mono_string_new
#2  0x000001021f1169 in mono_string_new_wrapper
#3  0x0000011ff61e6e in  (wrapper managed-to-native) object:__icall_wrapper_mono_string_new_wrapper (intptr) + 0x5e (0x11ff61e10 0x11ff61e84) [0x10ad9dcc0 - Unity Root Domain]
#4  0x0000011ffc74df in  (wrapper managed-to-native) DiscordRpc:RunCallbacks () + 0x5f (0x11ffc7480 0x11ffc74f0) [0x10ad9dcc0 - Unity Root Domain]
#5  0x000001020bef5a in mono_jit_runtime_invoke
#6  0x000001021ea406 in mono_runtime_invoke
#7  0x000001009ed4d9 in ScriptingInvocation::Invoke(ScriptingExceptionPtr*, bool)
#8  0x00000100c6f5c8 in MonoBehaviour::CallUpdateMethod(int)
#9  0x000001005e87a5 in void BaseBehaviourManager::CommonUpdate<BehaviourManager>()
#10 0x000001008150a0 in PlayerLoop()
#11 0x00000100e5d709 in -[PlayerAppDelegate UpdatePlayer]
#12 0x007fff36b2a5b9 in __NSFireTimer
#13 0x007fff349dcbb4 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
#14 0x007fff349dc827 in __CFRunLoopDoTimer
#15 0x007fff349dc32a in __CFRunLoopDoTimers
#16 0x007fff349d392b in __CFRunLoopRun
#17 0x007fff349d2d23 in CFRunLoopRunSpecific
#18 0x007fff33ceae26 in RunCurrentEventLoopInMode
#19 0x007fff33ceab96 in ReceiveNextEventCommon
#20 0x007fff33cea914 in _BlockUntilNextEventMatchingListInModeWithFilter
#21 0x007fff31fb5f5f in _DPSNextEvent
#22 0x007fff3274bb4c in -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]
#23 0x000001020857df in -[NSApplication(SteamOverrideNextEvent) steamhooked_nextEventMatchingMask:untilDate:inMode:dequeue:]
#24 0x007fff31faad6d in -[NSApplication run]
#25 0x007fff31f79f1a in NSApplicationMain
#26 0x00000100e5d2c5 in PlayerMain(int, char const**)
#27 0x00000100001e34 in start

[MinnDevelopment]

This looks like an error coming from one of the callbacks.

[dylanh724]

Ah, I had a backup file that it seemed to pick up as if it wasn't a backup. My users don't crash anymore, but RP doesn't work. Works fine on Linux and Windows, so leads me to believe it's something in the dylib (I followed placement instructions very carefully on the Unity tutorial), as suggested above. I'm waiting to find new logs from a Mac user.

EDIT: Fixed typo (Works fine on Linux [not Mac] and Windows)

[DeJayDev]

We believe the same thing @dylanh724. Investigating why the library has this issue on Mac is a personal priority

[msciotti]

I'm confused.

My users don't crash anymore, but RP doesn't work. Works fine on Mac and Windows, so leads me to believe it's something in the dylib

What do you mean by it works fine on mac and windows if RP isn't working? Is it not crashing, but RP isn't working? Is everything working on mac and windows, but not on linux?

[dylanh724]

@msciotti Typo: Works fine on Linux + Windows, rather

[msciotti]

@dylanh724 OK thank you for the clarification. Your original comment in this thread was about another crash. Is that what you're trying to solve right now, or are you also noting that game registration on macOS is not working?

If it is a different issue, could I please ask you to open a new issue here? Just to keep things on topic and help my brain stay organized lol

[DeJayDev]

A little bit of an update from my side:

I recently got a MacBook Air to test this issue (and for other reasons) and in my investigation learned more about the Mac OS and how URLs are handled: Whenever an app runs LSRegisterURL (in our case the Discord SDK) it writes to a handy little file that can be read with:
defaults read com.apple.LaunchServices/com.apple.launchservices.secure

Here's a snippet of an example output:

You can see the URL scheme, and the app meant to handle it. My prime example being FaceTime. I don't know the URI scheme, but I know that FaceTime:// (put this in your browser to see your OS handle this link) attempts to start a new FaceTime call, and as you can see it's doing what it should. FaceTime intercepts the URI request.

@MinnDevelopment's java-discord-rpc is also in the above image being used by IntelliJ through @sorenbug's discord-intellij. (This integration works, as explained below.)

The issue comes down to how the process using the SDK is being started. When it is started through a verified app with a real handle on the OS everything is okay. But when it's started through the JDK there's two different layers of sandboxing and virtualization and the impl simply cannot call out to Discord and run the Ready Callbacks regardless of how much modding I do to the SDK myself:

This example (logging prefixed with J:) is the send-presence example provided by Discord. The "direct" interface C++ provides to the OS doesn't stop it from doing it's job (see the successful LSRegisterURL result of 0).

Though, the same SDK mod on Vatuu/discord-rpc results:
Sorry for the formatting, can't do much about it and I've already gotten rid of it.

Simply, no LSRegisterURL fires.

I fear this may be impossible to do through Java.

[RealAlphabet]

Any idea ?

[msciotti]

Since this got necro'd a bit—it seems that it is unfortunately not possible to work around this LSRegisterURL and have it work within the JVM. I recommend explicitly using ReigsterCommand(), which we know works.

With the digging that we've done in this thread, and the deprecated status of this SDK, I'll close this as a can't/won't fix.