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

Figure out why appbundler breaks OpenGL when built on Catalina and later #284

Open
processing-bot opened this issue Oct 4, 2021 · 7 comments
Labels
help wanted Extra attention is needed high priority macos

Comments

@processing-bot
Copy link
Collaborator

Created by: benfry

As seen in #249, Export to Application was broken in alpha 5 and beta 1. This was after the native code for JavaApplicationStub was built on Catalina or Big Sur. Using a Mojave machine got things working again.

As can be seen in #249, it seems to be a threading issue (GL seems to be running on the wrong thread). I suspect there's something bad in our code, and that the Catalina/Big Sur change is just revealing it. Can someone help us find it?

It's also not a problem in our fork of appbundler: recompiling with the latest upstream source (on Big Sur) led to the same crash.

It's also possible that the macOS SDK has had a change with with regards to app threads. The -XstartOnFirstThread [parameter](https://www.google.com/search?q='Reference to deleted milestone 22'-xstartonfirstthread%22) is a very real thing on macOS, where app threads are Thinked Differently than on other platforms.

To dig into this issue:

cd build/macosx/appbundler
ant
cd ../..
ant run

Then open an OpenGL sketch, Export to Application, and watch as it crashes on startup. Behold the confusing stack trace. Or perhaps if you have more macOS development experience, become invigorated by the challenge of un-mucking this Java/macOS integration.

(Edited for clarification)

@processing-bot
Copy link
Collaborator Author

Created by: tmatinla

Found this: OpenGL incompatibility

Most of the solutions seem to either build against older macOS SDK or have changed the code so that OpenGL context initialization is done on the UI thread (if I understand this correctly). For example, https://github.com/google/filament/pull/1959/files says

    // NOTE: This is not documented well (if at all) but Apple requires the following two
    // context methods to be called from the UI thread. This became a hard requirement with the
    // arrival of macOS 10.15 (Catalina). If we were to call these methods from the GL thread,
    // we would see EXC_BAD_INSTRUCTION.

With my limited knowledge, I tried adding -XstartOnFirstThread, but instead of crash nothing happens (same thing as mentioned in the issue comment).

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Ah, thanks for finding that… At least I'm not losing it, though disappointing that more eyes on it hasn't actually produced a solution.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

And by “nothing happens” do you mean that Processing doesn't even start up when used with that appbundler? Or that nothing happens when running a sketch that uses OpenGL?

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Also adding the -XstartOnFirstThread reference from SWT: https://www.eclipse.org/swt/faq.php#swtawtosxmore

@processing-bot
Copy link
Collaborator Author

Created by: tmatinla

I mean that if I add -XstartOnFirstThread to the parameters of the exported application (for example, by modifying generated Info.plist file and adding it to JVMOptions array), the java process just hangs right after the start and nothing is displayed. I need to "force quit" the process to get rid of it.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Got it, thanks.

@processing-bot
Copy link
Collaborator Author

Created by: benfry

Upstream issue for this problem: TheInfiniteKind/appbundler#70

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed high priority macos
Projects
None yet
Development

No branches or pull requests

1 participant