Exported Application broken in 4.0 beta 1 on macOS when using P2D or P3D #249
Comments
|
Created by: codeanticode Confirming that it affects my MacOS Big Sur machine (m1 macbook air). I'm attaching the full error log. |
|
Created by: benfry Does that mean you're looking into it? Might be Java 11.0.12 versus 11.0.11, since it's crashing inside the JVM. We should also see if there are any JOGL reports/updates for this. |
|
Created by: codeanticode I'll look into it on the m1 macbook, and will update as I find more. |
|
Created by: codeanticode This error in the log seems telling: @benfry could it be that the application is not running on the correct thread when exported? |
|
Created by: sampottinger Sorry @philipp-lehmann just confirming this was happening in 3 as well? Digging into the jogl bugs, the only thing that stood out was https://jogamp.org/bugzilla/show_bug.cgi?id=1398 but I'm guessing it's something with launch4j and a fork. |
|
Created by: sampottinger Including or excluding the runtime does not help. Unfortunately 11.0.11 doesn't have a release on adoptium. :-/ |
|
Created by: philipp-lehmann With 3.5.4 I was able to export P3D applications. However on M1 Macs they only showed a gray screen, as described here: https://discourse.processing.org/t/problems-with-p2d-and-p3d-renderers-with-new-apple-m1-processor/27287 Edit: This still could be this issue? processing/processing#5983 |
|
Created by: philipp-lehmann Would it theoretically be possible to include a different jre, optimized for the m1 architecture, for the exported application? Or is this the wrong approach? Idea is from here: |
|
Created by: REAS When exporting with "Embed Java" received this in the command line: |
|
Created by: REAS When exporting without embedding Java, this was reported on the command line, which look like i need to update the Java version locally, but nothing is reported unless it's opened through the command line: |
|
Created by: matejsemancik I just came across this issue while trying to solve this exact error in my application builds. The issue started to appear with Azul OpenJDK to 11.0.12. I downgraded to 11.0.11 and issue went away. |
|
Created by: philipp-lehmann Thats something, how did you tell your exported application which version of the JDK to use? |
|
Created by: matejsemancik Well, since I use the Gradle build system, it's pretty straightforward. I just set the |
|
Created by: benfry
Not that simple; longer explanation here: #128 (comment) |
|
Created by: benfry
The |
|
Created by: benfry
Certainly possible, but I don't know why that would be different between Java 11.0.10 and 11.0.11 (if the report that it actually works with 11.0.10 is correct). It's a fairly major change, though I guess it could be a matter of enforcement. |
|
Created by: benfry 10.0.10 from AdoptOpenJDK doesn't seem to be working (though I haven't tried with the Azul builds), so I think it's just plain broken. It's obviously a threading issue, but I've not yet been able to identify what changed/broke that's now causing the problem. In fact, very rarely, it works just fine: I just double-clicked a test In the meantime, here's a workaround for folks who are desperate:
Now you can copy that Again, not an ideal solution, but it works in the meantime. #!/usr/bin/python3
import os
import plistlib
import sys
def find_first_dot_app(path):
''' what's the name of the .app for the sketch? '''
with os.scandir(path) as it:
for entry in it:
if entry.name.endswith('.app') and entry.is_dir():
return entry.path
def find_jdk_path(app_path):
''' figure out the path to the JDK in the PlugIns directory '''
path = f'{app_path}/Contents/PlugIns'
with os.scandir(path) as it:
for entry in it:
if entry.name.startswith('jdk-') and entry.is_dir():
return entry.path
return None
def find_jars(app_path):
''' return the full paths for all .jar files, separate with : '''
path = f'{app_path}/Contents/Java'
jar_paths = [ ]
with os.scandir(path) as it:
for entry in it:
if entry.name.endswith('.jar') and entry.is_file():
jar_paths.append(entry.path)
return ':'.join(jar_paths)
def find_main_class(app_path):
''' parse the Info.plist file to get the name of the sketch '''
with open(f'{app_path}/Contents/Info.plist', 'rb') as f:
pl = plistlib.load(f)
return pl['JVMMainClassName']
def process_exec(args):
''' run a process and get output from it '''
from subprocess import Popen, PIPE
p = Popen(args, stdout=PIPE, stderr=PIPE)
(out_data, err_data) = p.communicate()
result = p.wait()
return (result, out_data.decode('utf-8'), err_data.decode('utf-8'))
if __name__ == "__main__":
# the current directory
HERE = os.path.dirname(os.path.realpath(__file__))
dot_app = find_first_dot_app(HERE)
# print(dot_app)
jdk_path = find_jdk_path(dot_app)
if jdk_path:
# use an embedded JDK
cmd = [ f'{jdk_path}/Contents/Home/bin/java' ]
else:
# use built-in java_home to identify a Java 11 version
cmd = [ '/usr/libexec/java_home', '--version', '11', '--exec', 'java' ]
cmd += [ '-cp', find_jars(dot_app) ]
sketch_name = find_main_class(dot_app)
cmd += [ 'processing.core.PApplet', sketch_name ]
# run the command, wait, and print the result when the app finishes
(result, out, err) = process_exec(cmd)
sys.stderr.write(err)
sys.stdout.write(out)
if result != 0:
print(f'Exit code was {result}.') |
|
Created by: benfry For anyone looking into this further: my current theory is that we have some (older) code that's not being run from the correct thread. And it wasn't a problem before, but a recent OS update or something similar may have been enough to trigger something that was waiting to break. (This was working fine in my testing before recent releases… Export to Application with an OpenGL sketch is usually one of the things I'll test before putting out a release.) I've tried shutting off the AWT ( Edit: it also seems to be working with alpha 4, and broken in alpha 5. So that may be another clue (though the breaking is inconsistent, so that's not 100% certain…) |
|
Created by: benfry Have tracked it down to changes in the macOS app launcher between alpha 4 and 5… fix should be coming soon. |
|
Created by: benfry !@#$!% and it's caused by the launcher being recompiled… not the result of any actual changes. So either something has changed in the macOS SDK, or the recompile is just enough to trigger a threading problem that's present. |
|
Created by: benfry Now fixed for beta 2 by compiling appbundler on a Mojave machine instead of Catalina or Big Sur. If you can't wait for beta 2, replace |
|
Created by: philipp-lehmann Thanks for the Update and all your work. I'll test this soon. |
|
Created by: philipp-lehmann I can confirm that this works again. Awesome!!! |
|
Created by: benfry Great, thanks for reporting back. |
|
Created by: github-actions[bot] This issue has been automatically locked. To avoid confusion with reports that have already been resolved, closed issues are automatically locked 30 days after the last comment. Please open a new issue for related bugs. |
Created by: philipp-lehmann
Description
When opening an exported application, it immediately quits and MacOS displays an alert saying that the application "quit unexpectedly".
Previous Bug Report
This has been an issue a while back (processing/processing#5983), so maybe its my environment.
However I tried a clean new installation with a very simple sketch and couldn't export a functional app.
Steps to Reproduce
Environment
My Test Sketch
The error messages
The text was updated successfully, but these errors were encountered: