Community
Participate
Working Groups
Build Identifier: I20120518-2145 This was 1st noticed in 4.2M7 but I figured it would be fixed in the next milestone and reverted to using 4.2M6 which has never caused the condition. When checking out code using theperforce plug-in, the IDE will lost the ability to manipulate file permissions. As an example, I can have a file be read only and then try and make a change to it. Perforce will see that I am trying to change the file and will check the file out and update the resource's icon in the UI to have a checked out annotation on it. However, the file will not have been set to read/write. Worst, opening the properties dialog on ANY file in the IDE (perforce enabled or not) now has no permissions section on OSX at all. If I manually modify the file on the filesystem and then refresh then I can work as normal. However, the only fix is to recreate the workspace which wouldn't be so bad if it didn't keep happening. Reproducible: Always
Created attachment 216089 [details] Resource's properties dialog under 4.2M6
Created attachment 216090 [details] Resource's properties dialog under 4.2RC1 with perforce
Created attachment 216091 [details] Resource's properties dialog under 4.2RC1 without perforce
I can see the permissions controls on 3.8 M7 and RC1 on Linux. I also tried it on Mac with 3.8 M7 and it works there as well.
Hmm, I see the permissions under RC1. If you want to try some debugging, put a breakpoint in the org.eclipse.ui.internal.ide.dialogs.ResourceInfoPage#getFileSystemAttributes() and isPermissionsSupport() (found in org.eclipse.ui.ide).
I'll try the debugging info later tonight when I'm back at the mac.
Found the issue. The problem is that Eclipse is not using the latest Oracle jdk on OSX. Not saying you had to, just that by not using it the problem is easily missed. Basically the UnixFileNatives class has a static block to load the appropriate dynamic library, however for the latest Oracle jdk7 release the extension of the native library has changed from jnilib to dylib. The osx fragment only has the os/macosx/libunixfile_1_0_0.jnilib native library in it and thus it fails to load. Easily verified by running the following program with different execution envs. public class Test { public static void main(String[] args) { String libName = System.mapLibraryName("unixfile_1_0_0"); String javaVersion = System.getProperty("java.version"); System.out.println(javaVersion + " : " + libName); } } Running it for Java 7 and Java 6 gives: 1.7.0_04 : libunixfile_1_0_0.dylib 1.6.0_31 : libunixfile_1_0_0.jnilib The fix is to update the build to include the osx native lib in the fragment jar with both extensions. Once I did this then all is right with the world again.
I wondered why SWT is not affected by the same problem. Looks like they work around it in org.eclipse.swt.internal.Library.mapLibraryName(String): static String mapLibraryName (String libName) { /* SWT libraries in the Macintosh use the extension .jnilib but the some VMs map to .dylib. */ libName = System.mapLibraryName (libName); String ext = ".dylib"; //$NON-NLS-1$ if (libName.endsWith(ext)) { libName = libName.substring(0, libName.length() - ext.length()) + ".jnilib"; //$NON-NLS-1$ } return libName; }
After googling a bit, I think this is a bug in Oracle's jdk7 that should be fixed there. See e.g.: http://comments.gmane.org/gmane.comp.java.openjdk.core-libs.devel/9076 Another client of System.loadLibrary(..) that could be affected is in org.eclipse.equinox.security.macosx in the class OSXProvider.
I do not have access to Mac today, but will have on Monday. Markus suggested it may be a problem with missing x64 fragment for Mac. As I recall the fragment we have should work well on x32, x64 and ppc. Does the problem happen on x32. x64 or both?
Hmm, looks like the problem is in Equinox, where the call to System#loadLibrary(String) ends up. org.eclipse.core.runtime.internal.adaptor.EclipseClassLoadingHook#findLibrary(BaseData, String) performs String mappedLibName = System.mapLibraryName(libName); , which returns "libunixfile_1_0_0.jnilib" on an Apple 1.6 VM and "libunixfile_1_0_0.dylib" with Oracle jdk7_u4. BaseClassLoadingHook#mapLibraryNames(String) looks like it should rescue the situation, but it seems that ".jnilib" and ".dylib" are not registered in that magic "[org.]osgi.framework.library.extensions" property. Tom, do you know if/how this should work?
I confirmed that this is not a 32/64-bit problem. When I set a breakpoint at org.eclipse.core.runtime.internal.adaptor.EclipseClassLoadingHook#findLibrary(BaseData, String): line 195 with condition mappedLibName= "lib" + libName + ".jnilib"; return false; , then the library is properly loaded and works with Oracle jdk7_u4.
Can you try setting the following into the config.ini? org.osgi.framework.library.extensions=jnilib That will cause the framework to search for the extension jnilib after it fails to find the dylib one returned by System.mapLibraryName
(In reply to comment #13) > Can you try setting the following into the config.ini? > > org.osgi.framework.library.extensions=jnilib Yep, that solves the problem. Can you set this by default on the Mac? (In reply to comment #9) > [..] I think this is a bug in Oracle's jdk7 [..] Sorry, I think that was wrong. I didn't try out actual examples, but from the code I saw while stepping through this problem, I think jdk7 tries both in System#loadLibrary(String). OTOH, the API "String mapLibraryName(String libname)" is just too narrow for platforms that support multiple naming patterns.
(In reply to comment #14) > (In reply to comment #13) > > Can you try setting the following into the config.ini? > > > > org.osgi.framework.library.extensions=jnilib > > Yep, that solves the problem. Can you set this by default on the Mac? We can consider that, but I am not sure if it should be backed into the framework. Perhaps it should be placed in the config.ini for Mac? > > > (In reply to comment #9) > > [..] I think this is a bug in Oracle's jdk7 [..] > > Sorry, I think that was wrong. I didn't try out actual examples, but from the > code I saw while stepping through this problem, I think jdk7 tries both in > System#loadLibrary(String). > OTOH, the API "String mapLibraryName(String libname)" is just too narrow for > platforms that support multiple naming patterns. Still seems like a regression for mapLibraryName to all of a sudden use a different default for the library extension. But I guess I can't argue that point to much since we do sometimes change the defaults in Eclipse ;-)
(In reply to comment #14) > (In reply to comment #13) > > Can you try setting the following into the config.ini? > > > > org.osgi.framework.library.extensions=jnilib > > Yep, that solves the problem. Can you set this by default on the Mac? I can confirm it solves the problem for me too. I tried to change platform.product and sdk.product in eclipsebuilder repo. I can't set OS-specific config properties though. Is it a bug or it just works this way?
(In reply to comment #0) > This was 1st noticed in 4.2M7 but I figured it would be fixed in the next > milestone and reverted to using 4.2M6 which has never caused the condition. > When checking out code using theperforce plug-in, the IDE will lost the ability > to manipulate file permissions. Does anyone understand why this only started failing in 4.2 M7? Most of the discussion here is about a change in the underlying JRE, which wouldn't explain a regression in our code. Or is the above statement incorrect and it also occurs on 4.2 M6?
(In reply to comment #17) > Does anyone understand why this only started failing in 4.2 M7? Most of the > discussion here is about a change in the underlying JRE, which wouldn't explain > a regression in our code. Or is the above statement incorrect and it also > occurs on 4.2 M6? I'm able to reproduce the problem on 4.2M6.
(In reply to comment #18) > I'm able to reproduce the problem on 4.2M6. ... and setting org.osgi.framework.library.extensions=jnilib in config.ini helps too in this case.
For reference bug 276564 is where the change was discussed for SWT (three years ago). I'm still confused why this was never noticed before now. Also, it looks like this was acknowledged as a bug in OpenJDK and has been fixed in the latest update - fixed in 7u4(b20), 8(b34): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7134701
(In reply to comment #20) > For reference bug 276564 is where the change was discussed for SWT (three years > ago). I'm still confused why this was never noticed before now. > > Also, it looks like this was acknowledged as a bug in OpenJDK and has been > fixed in the latest update - fixed in 7u4(b20), 8(b34): > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7134701 I was testing using Oracle jvm 7u4 and I was still able to reproduce the bug. If I understand Tom well, the problem is also in EclipseClassLoadingHook#findLibrary that's why he suggested to add the property to config.ini.
Created attachment 216348 [details] Macosx makefile update
Here are the options I can think of: 1) Add setting to config.ini. This will solve the problem for all libraries in the Eclipse SDK but not for any other Eclipse product. We could also recommend the EPP products add this, but there are many Eclipse products out there. 2) Make a change in BaseClassLoadingHook where we add "dylib" to the extension list on mac "for free". This would solve it for all libraries in all equinox applications. 3) Rename our libraries to have .dylib extension on Mac 4) Do nothing and hope the next OpenJDK update on Mac has the fix. These options aren't mutually exclusive.. I think we should do 3) at some point because my reading of the source material is that "dylib" has been the standard on Mac JDK code which we really shouldn't rely on. For Juno I'm leaning towards option 2), but I could imagine deferring to SR1 if we think that is risky.
(In reply to comment #23) > These options aren't mutually exclusive.. I think we should do 3) at some point > because my reading of the source material is that "dylib" has been the standard > on Mac JDK code which we really shouldn't rely on. This sentence got mangled... I meant to write: "dylib" has been the standard on Mac for several years, and we have been saved by a compatibility hack in the Apple JDK which we really shouldn't rely on.
Changing the suffix to .dylib for Macosx filesystem lib fixes the problem. Tested on Oracle jvm 6 and 7.
(In reply to comment #23) > Here are the options I can think of: > > 1) Add setting to config.ini. This will solve the problem for all libraries in > the Eclipse SDK but not for any other Eclipse product. We could also recommend > the EPP products add this, but there are many Eclipse products out there. > > 2) Make a change in BaseClassLoadingHook where we add "dylib" to the extension > list on mac "for free". This would solve it for all libraries in all equinox > applications. > > 3) Rename our libraries to have .dylib extension on Mac > > 4) Do nothing and hope the next OpenJDK update on Mac has the fix. > > These options aren't mutually exclusive.. I think we should do 3) at some point > because my reading of the source material is that "dylib" has been the standard > on Mac JDK code which we really shouldn't rely on. > > For Juno I'm leaning towards option 2), but I could imagine deferring to SR1 if > we think that is risky. Can't we do 3) for filesystem fragments in Juno? This is just one lib.
Created attachment 216395 [details] Sets defaults for Mac OS to dylib and jnilib (In reply to comment #23) > Here are the options I can think of: > > 1) Add setting to config.ini. This will solve the problem for all libraries in > the Eclipse SDK but not for any other Eclipse product. We could also recommend > the EPP products add this, but there are many Eclipse products out there. I think this has some logistical issues in getting that rolled out. > > 2) Make a change in BaseClassLoadingHook where we add "dylib" to the extension > list on mac "for free". This would solve it for all libraries in all equinox > applications. This is the most safe change, but I would make the list jnilib and dylib so that it does not matter if you are running on Java 6 or 7 the same libraries will be searched for. > > 3) Rename our libraries to have .dylib extension on Mac We cannot rename since that will break Java 6 where the old extension is still used and we do not searcy for dylib > > 4) Do nothing and hope the next OpenJDK update on Mac has the fix. I'm not sure there is a good answer here because the JRE can only return a single mapped name. We would need an API change in the JRE to call a method that mapped a library name into multiple possible file names. > > These options aren't mutually exclusive.. I think we should do 3) at some point > because my reading of the source material is that "dylib" has been the standard > on Mac JDK code which we really shouldn't rely on. > > For Juno I'm leaning towards option 2), but I could imagine deferring to SR1 if > we think that is risky. Here is the patch for option 2)
John, please review. I am leaning towards deferring to SR1.
(In reply to comment #20) > I'm still confused why this was never noticed before now. The problem is manifold, and you need to have a very specific setup to notice it: - need to run the cocoa-x86_64 build (since there's no Oracle 32-bit VM, the 32bit build will fall back to using Apple's VMs) - need to have Oracle JDK7 installed and high enough in the Java Preferences.app - need to care about platform-specific filesystem properties. SWT didn't load at all. But here, only some functionality is not available, and there's not even a log entry (because UnixFileSystem#isLibraryPresent(..) suffers from the same problem). (In reply to comment #26) > Can't we do 3) for filesystem fragments in Juno? This is just one lib. No, I verified that this doesn't work with Apple JVMs (because System#mapLibraryName(..) uses jnilib there). And apart from SWT, the SDK contains a third native library: org.eclipse.equinox.security.macosx/libkeystoreNative.jnilib (In reply to comment #23) > 4) Do nothing and hope the next OpenJDK update on Mac has the fix. I don't think they will change anything. They have their fallback code in System#loadLibrary(String). Our problem is that we don't have the library on the native path. Equinox should find the library, but it can't since System#mapLibraryName(..) has been changed and only supports one format. (1) and (2) are the only options we have, and I think we should do (2) for Juno. I'll test the patch.
I released the patch for RC3 in commit: http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=42fa725f1676bac25db2747488d0d32bdbda5cd8
Can a Mac user verify this? The fix will be available in Juno RC3, which should be available this evening or tomorrow.
Verified working for me on OSX with the latest Oracle jvm.
Verified in 4.2 and 3.8 RC3
