Community
Participate
Working Groups
I have successfully installed eclipse (eclipse-SDK-I20210429-1800-macosx-cocoa-aarch64.dmg) on a new Mac mini and it worked fine, could install some plugins and was able to restart eclipse. But: after restarting the Mac when I try to open eclipse again, I always get an error: "The application cannot be opened for an unexpected reason, error=Error Domain=NSOSStatusErrorDomain Code=-10826 "kLSNoLaunchPermissionErr: User doesn't have permission to launch the app (managed networks)" UserInfo={_LSFunction=_LSLaunchWithRunningboard, _LSLine=2508, NSUnderlyingError=0x15400af30 {Error Domain=RBSRequestErrorDomain Code=5 "Launch failed." UserInfo={NSLocalizedFailureReason=Launch failed., NSUnderlyingError=0x154007090 {Error Domain=NSPOSIXErrorDomain Code=153 "Unknown error: 153" UserInfo={NSLocalizedDescription=Launchd job spawn failed with error: 153}}}}}" I already tried some tipps from StackExchange, but none of these work for me: - sudo chown -R 0755 /Applications/Eclipse.app/ - sudo xattr -dr com.apple.quarantine /Applications/Eclipse.app/ - sudo upx -d sudo upx -d /Applications/Eclipse.app/Contents/MacOS/eclipse This is reproducible for me. I deleted eclipse, reinstalled it (and unfortunately had to reinstall my plugins), but after restarting the computer I get the same error message again.
Hi, thanks for trying out the Mac aarch64 build. I'm unable to test this scenario currently. The error reported was seen in the earlier builds due to a problem with the eclipse executable, but has been fixed. Please see Bug 572115 for the details. Do you have the old builds by any chance? If not, please check if the eclipse executable changes before and after restart -> ls -l /Applications/Eclipse.app/Contents/MacOS/eclipse
My eclipse version is: 2021-06 (4.20) Build id: I20210429-1800 Thanks for the reply. I was able to dig a little deeper using the information of Bug 572115. I do no longer think the machine reboot is the reason but maybe the plugin installation. I renamed my non working installation to EclipseNotWorking.app and did a fresh installation of eclipse-SDK-I20210429-1800-macosx-cocoa-aarch64.dmg to Eclipse.app. The executables are the same: --- BEGIN --- d@mini /Applications % ls -l /Applications/Eclipse.app/Contents/MacOS/eclipse -rwxr-xr-x@ 1 d admin 75280 29 Apr 18:43 /Applications/Eclipse.app/Contents/MacOS/eclipse d@mini /Applications % ls -l /Applications/EclipseNotWorking.app/Contents/MacOS/eclipse -rwxr-xr-x@ 1 d admin 75280 29 Apr 18:43 /Applications/EclipseNotWorking.app/Contents/MacOS/eclipse --- END --- Verifying those two installations leads to --- BEGIN --- d@mini /Applications % codesign --verify --verbose Eclipse.app Eclipse.app: valid on disk Eclipse.app: satisfies its Designated Requirement d@mini /Applications % codesign --verify --verbose EclipseNotWorking.app EclipseNotWorking.app: invalid Info.plist (plist or signature have been modified) In architecture: arm64 --- END--- Then I compared the differing Info.plists: --- BEGIN --- d@mini /Applications % diff Eclipse.app/Contents/Info.plist EclipseNotWorking.app/Contents/Info.plist 1,2c1 < <?xml version="1.0" encoding="UTF-8" standalone="no"?> < <plist version="1.0"> --- > <?xml version="1.0" encoding="UTF-8" standalone="no"?><plist version="1.0"> 72c71,82 < </dict> --- > <key>CFBundleURLTypes</key> > <array> > <dict> > <key>CFBundleURLName</key> > <string>XDebug file link</string> > <key>CFBundleURLSchemes</key> > <array> > <string>xdebug</string> > </array> > </dict> > </array> > </dict> 74c84 < </plist> --- > </plist> \ No newline at end of file --- END--- I think the Info.plist was modified when I installed the plugins. I restored the Info.plist by copying the Info.plist from the fresh installation: cp Eclipse.app/Contents/Info.plist EclipseNotWorking.app/Contents/Info.plist When I check with codesign again I now get: --- BEGIN --- d@mini /Applications % codesign --verify --verbose EclipseNotWorking.app EclipseNotWorking.app: a sealed resource is missing or invalid file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.update/history/1619739704000.xml file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.core.runtime/.table.3 file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.core.runtime/.contributions.3 file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.core.runtime/.extraData.3 ... looong list of other file additions removed file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/features/org.eclipse.gef_3.11.0.201606061308/epl-v10.html file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/features/org.eclipse.gef_3.11.0.201606061308/feature.properties file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/epl-v10.html file added: /Applications/EclipseNotWorking.app/Contents/Eclipse/notice.html file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/eclipse.ini file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.update/platform.xml file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.equinox.simpleconfigurator/.baseBundlesInfoTimestamp file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/config.ini file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.equinox.source/source.info file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/configuration/org.eclipse.equinox.simpleconfigurator/bundles.info file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/.settings/org.eclipse.equinox.p2.metadata.repository.prefs file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/p2/org.eclipse.equinox.p2.engine/profileRegistry/SDKProfile.profile/.data/.settings/org.eclipse.equinox.p2.artifact.repository.prefs file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/p2/org.eclipse.equinox.p2.core/cache/artifacts.xml file modified: /Applications/EclipseNotWorking.app/Contents/Eclipse/artifacts.xml --- END --- I am not an experienced Apple user so I do not know if this is expected. I can now run the EclipseNotWorking.app again without the blocking error but unfortunately it does not start. It immediately exits. The /var/log/system.log says May 3 14:45:07 mini com.apple.xpc.launchd[1]: Coalition Cache Hit: app<application.org.eclipse.sdk.ide.892619.893939(501)> [763] May 3 14:45:07 mini com.apple.xpc.launchd[1] (application.org.eclipse.sdk.ide.892619.893939[975]): Service exited with abnormal code: 1
An addition to my last comment: if I rename EclipseNotWorking.app back to Eclipse.app then I am able to restart eclipse again. Therefore the main reason for the missing permission error seems to be the modified Info.plist.
(In reply to Dennis Logemann from comment #2) > My eclipse version is: 2021-06 (4.20) > Build id: I20210429-1800 > > Thanks for the reply. I was able to dig a little deeper using the > information of Bug 572115. I do no longer think the machine reboot is the > reason but maybe the plugin installation. > Can you specify which plugin you installed and the steps you followed, may be I can try it out? > I am not an experienced Apple user so I do not know if this is expected. > The Mac Eclipse app is signed, so modifying the Info.plist inside the Eclipse.app is causing this.
I had exactly the same problem. 1. download and install eclipse-SDK-I20210503-1800-macosx-cocoa-aarch64.dmg 2. add Java path in info.plist to zulu64-11.0.10 /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin/java 3. add plugins: - MarketPlace https://download.eclipse.org/mpc/releases/latest/ - Subeclipse 4.3.3 - Apache IvyDE - Maven Integration for Eclipse (Luna and newer) 1.5 - Markdown Text Editor 1.2.0 - GWT Eclipse Plugin 3.0 , only: - Eclipse Plugin - GWT 2.8.1 SDK - SDBG build from this issue https://github.com/sdbg/sdbg/issues/161 https://p2.sapsailing.com/p2/sdbg/ - Enhanced Class Decompiler 3.2.1 I repeated this 3 times starting from scratch. Each time after a full osx reboot, Eclipse stopped working, "You have no rights to run application". No known tricks helped Yesterday I did it again. However, a little different. 1. java updrade brew upgrade java /opt/homebrew/Cellar/openjdk/15.0.2/bin/java -version openjdk version "16" 2021-03-16 OpenJDK Runtime Environment (build 16+14) OpenJDK 64-Bit Server VM (build 16+14, mixed mode) Previously, it was 15.0.1 . Eclipse does not work at all with 15.0.1 on Big Sur M1. 2. download and install eclipse-SDK-I20210518-1800-macosx-cocoa-aarch64.dmg https://download.eclipse.org/eclipse/downloads/drops4/I20210518-1800/download.php?dropFile=eclipse-SDK-I20210518-1800-macosx-cocoa-aarch64.dmg I left info.plist unchanged 3. add plugins: - MarketPlace https://download.eclipse.org/mpc/releases/latest/ - Subeclipse 4.3.3 - Apache IvyDE - Maven Integration for Eclipse (Luna and newer) 1.5 - GWT Eclipse Plugin 3.0 , only: - Eclipse Plugin - GWT 2.8.1 SDK I didn't install plugins that I thought were suspicious (SDBG, ECD) I restarted OSX after each operation above. Eclipse works fine so far BTW: Nice to see how fast it is. I have never seen an Eclipse take off so quickly before. Less than 3s to full responsiveness. So the source of the problem is unknown. This can be: 1. Java version 2. modification of the info.plist file inside the package 3. additional plugins I will wait before taking these steps to be absolutely sure that the current configuration is working properly.
(In reply to Rafał Jastrzębski from comment #5) > I had exactly the same problem. > > 1. download and install eclipse-SDK-I20210503-1800-macosx-cocoa-aarch64.dmg > 2. add Java path in info.plist to zulu64-11.0.10 > /Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home/bin/java Thanks for the detailed steps. Looks like modifying Info.plist is causing the problem on Mac AArch64. Please add the java path to eclipse.ini instead of editing the Info.plist - https://wiki.eclipse.org/Eclipse.ini#-vm_value:_macOS_Example , also see the NOTE. > Yesterday I did it again. However, a little different. > 1. java updrade > brew upgrade java > > /opt/homebrew/Cellar/openjdk/15.0.2/bin/java -version > > openjdk version "16" 2021-03-16 > OpenJDK Runtime Environment (build 16+14) > OpenJDK 64-Bit Server VM (build 16+14, mixed mode) Only a aarch64 jvm can be used to launch Eclipse Mac aarch64, the x86_64 jvm will not be used. If both are installed on the machine, run /usr/libexec/java_home to check which VM is the default and will be used to launch eclipse. Also, you can check the JVM that was used to launch eclipse from About Eclipse > Installation > Configuration tab, search for vm or eclipse.vm.
Here is a solution that works for me to run Eclipse on macOS Bug Sur on m1 cpu with modified Info.plist/eclipse.ini https://www.eclipse.org/forums/index.php?t=msg&th=1108915&goto=1844554&#msg_1844554
Self modifying applications are really no go in MacOS. The issue happens every time I install/update plugins. The solution is to use external location (bundle pools) for installed plugins. Using Eclipse Installer to install IDE works for me. 2021-12 M2 Eclipse Installer for Apple silicone is available already: https://download.eclipse.org/justj/?file=oomph/epp/2021-12/M2 See https://bugs.eclipse.org/bugs/show_bug.cgi?id=576898
This bug is caused by adding a new URL protocol handler to PList.info. Mentioned functionality was added in https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835. This is not allowed in macOS for sealed applications and causes the app to be unbootable after the restart. This was found when investigating the issue: https://github.com/dbeaver/dbeaver/issues/14726. This breaks sealed RCP applications that depend on org.eclipse.urischeme and have any plugin with extension point org.eclipse.urischeme.uriSchemeHandlers on macOS.
(In reply to Georgy Gvinepadze from comment #9) > This bug is caused by adding a new URL protocol handler to PList.info. > Mentioned functionality was added in > https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835. > This is not allowed in macOS for sealed applications and causes the app to > be unbootable after the restart. This was found when investigating the > issue: https://github.com/dbeaver/dbeaver/issues/14726. > This breaks sealed RCP applications that depend on org.eclipse.urischeme and > have any plugin with extension point org.eclipse.urischeme.uriSchemeHandlers > on macOS. From https://bugs.eclipse.org/bugs/show_bug.cgi?id=530835#c52, this was discussed earlier and was considered not to cause a problem since the plist file is modified at runtime. Has anything changed causing the problem now? Adding Matthias for comments.
I am a pretty avid Eclipse user for a long time, same with using MacOS. I recently got a new MacBook Pro 2021 16 inch with MacOS Monterey 12.3.1 on it. I then proceeded to install from eclipse-php-2022-03-R-macosx-cocoa-aarch64.dmg (I am using the M1 chip which uses Apple Silicon). When I first ran it, no problem. I then proceeded to install several plugins from Marketplace. The following are the additions according to About Eclipse > Installation Details > Installation History: * Eclipse Java Development Tools 3.18.1100.v20220308-0310 * PyDev for Eclipse 9.3.0.202203051235 * Pydev Mylyn Integration 0.6.0 Everything else is the same as when first loaded. When I tried running Eclipse again, I got the issue as described in this ticket. Replacing the Eclipse.app/Contents/Info.plist file with the original from the dmg does allow Eclipse to load properly again. The diff between the files is as follows: $ diff Eclipse.app/Contents/Info.plist Info-broken.plist 1,2c1 < <?xml version="1.0" encoding="UTF-8" standalone="no"?> < <plist version="1.0"> --- > <?xml version="1.0" encoding="UTF-8" standalone="no"?><plist version="1.0"> 70c69,96 < </dict> --- > <key>CFBundleURLTypes</key> > <array> > <dict> > <key>CFBundleURLName</key> > <string>Eclipse command</string> > <key>CFBundleURLSchemes</key> > <array> > <string>eclipse+command</string> > </array> > </dict> > <dict> > <key>CFBundleURLName</key> > <string>Eclipse Marketplace</string> > <key>CFBundleURLSchemes</key> > <array> > <string>eclipse+mpc</string> > </array> > </dict> > <dict> > <key>CFBundleURLName</key> > <string>XDebug file link</string> > <key>CFBundleURLSchemes</key> > <array> > <string>xdebug</string> > </array> > </dict> > </array> > </dict> 72c98 < </plist> --- > </plist> \ No newline at end of file The configuration I had for years and never caused any issues was MacBook Pro 2018 15-inch, MacOS Catalina 10.15.7, "Eclipse IDE for PHP Developers build 20190614-1200". I just compared its Info.plist with a fresh download, and it is unaltered. I then made a manual change to the file and tried running it again, and it still worked fine. My assumption is therefore that more recent MacOS versions have a stricter policy on verifying signed code, and perhaps an earlier assumption on the part of Eclipse platform developers that it was safe to update Info.plist without bad side-effects is no longer true.
My workaround is to launch Eclipse once, close it then delete the _CodeSignature directory inside of Eclipse.app.
Created attachment 288659 [details] Stack dump for native code crash
Also true of MacOS x86_64 RCP package. The workaround in comment 12 allows me to launch eclipse, but then other functionality fails (e.g., maven fails to update projects due to loss of privileges to read removable volumes). The workaround in comment 7 works for me. It seems to clear permissions, so macOS re-queries the user on next launch. To repeat the email message here for convenience: 1. Open terminal 2. cd to folder containing Eclipse.app 3. Execute the commands: xattr -rd com.apple.quarantine Eclipse.app codesign --remove-signature Eclipse.app P2 or P1 seems apt since this bug blocks usage entirely with barely a workaround. Not an SWT bug.
I see comment 10 and comment 9 suggest that this is not a problem if/since eclipse is launched before modifying its contents. My practice is to edit the eclipse.ini file to change memory and VM settings, and my doing that before initial launch might have triggered the failure to launch. Note, however, the problem does not present until after restart: - install eclipse - edit eclipse.ini - eclipse launches and works normally - restart macOS - launch eclipse --> crash, failure to launch This delayed presentation makes the solution non-obvious to the user (if indeed editing the eclipse.ini is the cause). Note the recent bundling of the JRE might make hitting this bug more or less likely: - less likely if people rely on the bundled VM - more likely if people insist on their own (Indeed, I wonder if the self-modification flow is altered by the bundled JRE.) Nonetheless, I should add that perhaps part of the accepted workaround should be to edit eclipse.ini only after launching it once (and restarting macOS?).
Follow-up to my comment 11 Attempted this time with Eclipse Installer.app from Jun 8, 2022 without additional updates. Selected "Eclipse IDE for PHP Developers" Result was build id 20220609-1112 with a slightly different configuration than the last time I attempted. I restarted without doing anything further, success. I installed "Eclipse Java Development Tools 3.18.1200.v20220607-0700", restarted, success. I installed "PyDev - Python IDE for Eclipse 9.3.0" without "Pydev Mylyn Integration" (omitted due to missing requirements), success. This was as close as I could reproduce the original steps I outlined (though I installed in two passes and added an extra restart at the beginning). This time, Info.plist remains unmodified, which in turn means launching works just fine. Key takeaway: I am satisfied that my breaking scenario is not occurring anymore. If through usage I find it stops working for some reason unrelated to simple installation, I'll let you know. But until then, you can assume comment 11 is resolved.
(In reply to fa from comment #14) > It seems to clear permissions, so > macOS re-queries the user on next launch. To repeat the email message here > for convenience: > > 1. Open terminal > 2. cd to folder containing Eclipse.app > 3. Execute the commands: > > xattr -rd com.apple.quarantine Eclipse.app > codesign --remove-signature Eclipse.app For me re-signing Eclipse.app does the job: codesign --force --deep --sign - Eclipse.app
As per Benjamin Brandi's comment, code signing the application again did the trick for me with version 2022-09 on macOS Monterey 12.6 (refused to launch after upgrading the OS). Not very comfortable for users, but at least it works !
