At the end of my wits debugging a bizarre issue. M...

# compose-desktop

[David W]

At the end of my wits debugging a bizarre issue.
My CfD application launches another third-party Java application. That application fails to load some crucial .dll files and crashes, but only when my application is started using runDistributable. It runs fine when launched from my application if it's launched via run ; it only fails to load the dlls and crashes when built for dist.
Code here: <https://github.com/davidwhitman/SMOL/blob/dev/App/main/kotlin/smol_app/toolbar/Toolbar.kt#L148> and here <https://github.com/davidwhitman/SMOL/blob/dev/Utilities/main/kotlin/utilities/Utils.kt#L43>
Screenshots and stacktrace: <https://github.com/davidwhitman/SMOL/issues/73>
Things I've tried:
• ProcessBuilder and Runtime exec, same results.
• Copied the dll file to System32, which fixed the problem, I don't know why.
• Many various usages of ProcessBuilder and Runtime exe, same results.
• includeAllModules = true same results
• Viewed in VisualVM, noted that the java program I'm launching doesn't show up, presumably because it's a subprocess, but that's true even when it works correctly so not sure if relevant.
The other, crashing java program is given the dll path in env variable, but it successfully loads other dlls in the same path (and fails to load them if I rename them).

This is probably too complex/unique for anyone to want to dive deep into, but I'll take any suggestions.
One thing I'd like to try is launching the other java program as a standalone process, not a subprocess, but I haven't found a way to do this at all. cmd /C doesn't do it.
I should maybe mention that the reason I consider this Compose-related is the difference between it working using run and not working using runDistributable. There's something about the Compose build that's changing things.

update: Setting -Djava.library.path to an absolute path instead of relative seems to fix it. Doesn't make much sense to me, since it loads other .dlls from that folder without issue.
Now I just need to figure out how to get java path variables to allow spaces...
update: Just had to remove the cmd /C, probably the /C switch can't handle spaces in paths since it hands it all as a string.
My problem is solved, although I couldn't say why this solution works. It's probably a unique case, but I'll leave this post anyway because you never know.

[olonho]

from your description seems that current working directory is different in run vs runDistributable cases

[David W]

that was my first thought, too, but
• the other application prints the working dir on launch, and it's the same between both (and correct)
• the other application loads .dlls from that directory in both run scenarios, implying that it can find it. it fails to load them if i move or rename them, implying that it's using those dlls and not getting them from elsewhere

[David W]

the other application loads LWJGL, which in turn loads the OpenAL dlls (the ones that fail), so i think it's something about how LWJGL is loading those.
i looked at the source but couldn't figure it out, and couldn't figure out how to attach a debugger to that code.