Community
Participate
Working Groups
With the last patches and libs, my Eclipse crashes and I get this on my console: # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGFPE (0x8) at pc=0x007a350c, pid=11330, tid=3086923456 # # Java VM: Java HotSpot(TM) Client VM (1.4.2_14-b05 mixed mode) # Problematic frame: # C [ld-linux.so.2+0x850c] # # An error report file with more information is saved as hs_err_pid11330.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp #
This is probably happening because the binary is built incorrectly (I'm guessing). It was build on a Fedora 8 64 bit system, and I might not have correctly specified the options for a 32-bit .so. What type of system did this error happen on?
It is Red Hat AS 4. I think it is 32 bit OS (?)
Szymon, anyway you can attach the entire error report file? I verified that the binary I built was for a 32 bit system, so that was not the problem. I will try some things to try to reproduce the problem here. What do I need to run to get this called in the IDE? The only testing I have done with it is the junit tests, and it seems to react fine if some of the shared libraries are missing. Maybe the IDE behaves differently.
Francis, To test the stuff from IDE, you should get one of the latest Nbuilds. I think that I20080415-1646 is ok, despite the failed tests. Go to Window > Preferences > General > Network Connection and set the "System proxy configuration..." checkbox. Go to the CVS repos view and try to perform any operation on one of added repos. If you have any pserver one, it will use SOCKS proxy to connect.
Created attachment 96832 [details] linux.x86 native fragment
Created attachment 96833 [details] linux.x86 native fragment
Created attachment 96835 [details] Fix
Francis, System#getenv was deprecated in 1.4. When you try to call this method on Sun VM you will get an error. I'm not sure now... but I think that we should have native code for getting proxy properties on Linux too.
Created attachment 96991 [details] Initial patch
Native fragment and the initial patch released to HEAD.
Syzmon, I noticed you moved UnixProxyProvider into ....net.proxy.unix, yet WindowsProxyProvider is in internal.net. I think they should both be in the same place, so I am moving UnixProxyProvider back to internal.net (this affects the JNI code). If you disagree, I would be happy to leave it in .net.proxy.unix.
I want both windows and unix providers in separate packages. So the windows one will be moved to the win32 package.
Created attachment 97178 [details] Revised to use native getenv() and restructure native libs - *not tested* Here is the work so far. It's got some debugging prints in it and has not been tested due to difficulties I am having in getting the native libs to work. Other than the testing though, the coding is complete (as far as I know).
Created attachment 97179 [details] Binaries of the shared libs Though these were built on a 64 bit system, they are for 32 bit systems.
Created attachment 97399 [details] Revised and tested patch This has been revised to also handle the no_proxy environment variable as well as the correct handling of the Gnome use_same_proxy setting. Debug tracing and some error logging has also been added. This was tested on a 64-bit machine (though using a 32-bit JVM), and also tested on a 32-bit machine (running Gnome). This version has *not* been tested on a machine without Gnome (though that was tested previously). As far as I know there are no further outstanding issues with this code.
Created attachment 97400 [details] linux shared libraries for x86 (32 bit)
Created attachment 97566 [details] Patch revised to remove gnome portion, only uses getenv() This contains 244 lines of new code. It also contains some small changes to support bug 228739 (UI for proxy system values) which are easier to locate here rather than in that patch. That bug must depend on this one.
Created attachment 97567 [details] shared library for getenv() support I decided to keep the getenv() implementation native as it's actually less code than calling "env" from a process (to do it right is a surprising amount of code). This is simpler.
This bug report is rescoped to include only support for reading of the environment variables on Linux. The gnome support has been moved to bug 228738 which depends on code from this bug. With the lastest patches there are no known issues. I was able to reproduce the initial defect reported in comment #1 and confirm that it is related only to the gnome support. This issue has been addressed in the Gnome code to be submitted under bug 228738.
Created attachment 97582 [details] Get env not using native code
Patch from comment 21 released with some minor modifications. This was the final commit for this bug, marking as FIXED.
Verified by code inspection.
