Community
Participate
Working Groups
Created attachment 171635 [details] Plug-In project to reproduce When using fragment org.eclipse.core.net.win32.x86 on a Windows Vista or Windows 7 machine with an equinox/swing application the jvm crashes after some time. The reason is in the org.eclipse.core.net.win32.x86/jWinHttp-1.0.0.dll that conflicts with the jre native code on the windows ole32.dll It works fine on Windows 200 and XP, but fails on Windows Vista and 7. I made detailed analysis and created a simple hello world app to reproduce this. Please find attached a Plug-In project. Start the product bug.net.product This will start two eclipse jobs that re-schedule forever. One job simply calls IProxyService.select(URI). The other job constantly creates a swing frame with one text field. (JTextField have a DropTarget). When started on vista this crashes the jvm after some seconds on a "illegal access" in ole32.dll. Removing the org.eclipse.core.net.win32.x86 from the product does not lead to a crash. Question1: Does the win32.x86 implementation of IProxyService with jWinHttp-1.0.0.dll use ole32.dll (even indirectly)? Question2: Does it do any com/com+ functionality? Question3: What is the difference of WinXp and WinVista with regard to jWinHttp-1.0.0.dll? Does it use proper threading model and compartments?
Is there someone working on this? I will try to help finding a solution if i can. Can you at least give me an answer to my questions.
This is not only a e3.6 issue it also happens on the current e3.5.2, thats why i marked it critical.
Pawel, please investigate.
Checking the jre 1.6. native source code i found out that the jre 1.6 itself contains more or less the same functionality as programmed in the org.eclipse.core.net.win32.x86 fragment. It is the jre/lib/deploy.jar with the jre/lib/deploy.dll, works for mac osx, windows, unix. Why is that not used? I will give it a try creating a org.eclipse.core.net fragment using that jre code and try to reproduce the crash we have. In the meantime i would appreciate any feedback on this bug.
(In reply to comment #4) > Why is that not used? Platform runs on Java 1.4 at the moment. CCing Stefan, he provided the natives for Windows.
Thanks. The jre deploy.jar is since jre 1.5
The jWinHttp.dll does indeed use the OLE32.dll directly. It calls the CoInitialize/CoUninitialize as a proposed workaround by the kb entry: http://support.microsoft.com/?kbid=834742 My guess is that these calls are no longer necessary with vista and 7. Shall a solution for this be part of Helios?
Helios: yes, if possible. for 3.5.2 we will use a workaround using a fragment we will try to build based on the jre 1.5. deploy.jar If that fails, what could be an alternative to detecting auto proxy configs on windows vista with eclipse 3.5.2 ?
(In reply to comment #8) > If that fails, what could be an alternative to detecting auto proxy configs on > windows vista with eclipse 3.5.2 ? No other alternative comes to my mind.
I verified the crash. It does not occur on Win7 32bit but Win7 64bit. Which versions do you use?
WinXP/32bit/SP2 : no crash WinVista/32bit : crash Windows7/32bit : crash Details: "Microsoft Windows 7 Enterprise 6.1.7600 (32-Bit)"
I am just trying to rebuild the dll(s) debug/release but unfortunately the Eclipse IDE fails to load them. It starts up but, I can see for a short time the IDE and than it vanishes. No information about what happens - no logging to console, I used eclipsec.exe with -debug. Syzmon did you build the dlls?
Ok, back on the track. Can now build the dll and I will investigate.
(In reply to comment #12) > Szymon did you build the dlls? I used to build Windows dlls. I think I have still the build environment configured. So if you have any problems with it, ping me.
just my 2 cents here.... This is a bug that needs to be fixed, the sooner the better.....but most likely exists now for 2 years and is in my view NOT a P1 bug. Its highly unlikely that the higher gods of Helios would allow a fix to be brought in so late in the game. BSI had all their people vote for it :-) which is great but still... I highly recommend adjusting the prio to something more sensible. Again I am not denying that this is a critical bug, but we should reserve P1 for REAL P1's in my view.
Changed P1 to P3. However note that most of our customers are using that fragment to connect using auto-proxy detection. If we have to drop that fragment due to jvm crashes, these customers can NOT connect to their app server anymore, since the proxy.pac resolution is then broken. That is not just a minor issue. Many bsi people voting for that bug has to do exctly with that fact, since they are in different projects doing eclipse applications for customers on windows XP, Vista, 7.
If that bug exists for 2 years in windows vista, which is the bug for it? Can you please make a reference to this bug.
Christian is right, it won't be addressed in 3.6. Hope we can do it early in 3.7 cycle and backport the fix to 3.6.1.
What I meant is NOT that the bug is known for two years, but now that we know about this bug and since the code wasnt modified much (if at all) in the recent past, this bug must have been around for at least 2 years (thats what Stefan told me). It seems related the heavy use of ProxySelector and Swing. And as I said its a critical bug. Its just that this heavy use of ProxySelector and Swing is not very common in the Eclipse community (not talking about Windows 7 which is more and more coming up). So I believe thats the reason we didnt detect that problem earlier. So the two years should only underline the point that I vote against rolling back a release train (Helios) which had its final build one week ago (with 40 projects) to fix a bug that exists for so long undetected.
I meant it was discovered earlier, sorry. I absolutely agree with you in that manner.
Just a short update of my investigation. The CoInitialize/CoUninitialize are not responsible for the crash. If I remove them it still crashs. Neither are WinHttpOpen and WinHttpClose responsible for the crash. But if I omit the calls to - WinHttpGetIEProxyConfigForCurrentUser - WinHttpGetProxyForUrl - WinHttpDetectAutoProxyConfigUrl it does no crash. Activating just WinHttpGetIEProxyConfigForCurrentUser crashes.
thx for the update So it could also be an issue in the SUN jni code in awt.dll. There sun had previous bugs regarding the read of a window peer and - later - using that reference without checking to be null in the meantime. I analyzed the sun jre 1.6 jni native c++ code but did not find any location where there were such an async section or a section without double-check. So far i (unfortunately) have no additional info.
Pawel, please drive the discussion.
Stefan, the discussion seems to be stalled. Did you manage to investigate the problem further?
Here my contribution for further analysis: I created a sun-jre-1.6 based reference Plug-In using code from jre/lib/deploy.jar and indirectly using jre/bin/deploy.dll. Please find attached the org.eclipse.core.net.sun.win32.x86 fragment. When replacing the org.eclipse.core.net.win32.x86 by this plugin we have same functionality and it works on vista and win7 without crashing. The source code of sun's deploy jar and dll can be found on the sun jre download site. Maybe that helps finding the gap between the two native proxy selector C++ codes. Please note that the attached fragment Plug-In uses source code from sun and is therefore not covered by EPL nor is it valid as contribution code. It is solely intende as a reference implementation for further analysis.
Created attachment 173070 [details] Alternate fragment for jre 1.6+ using jre deploy part
Created attachment 173071 [details] As a convenience please find the sun jre proxy.cpp attached As a convenience please find the sun jre proxy.cpp attached
As a convenience i attached the sun jre proxy.cpp
(In reply to comment #24) Pawel, I have not forgotten this issue but we have been quite busy within the helios release train. And the next two weeks I will be on vacation. (in reply to comment #25) Thanks Ivan, I will take a look at it. Too bad that it has the "wrong" license!
> Thanks Ivan, I will take a look at it. Too bad that it has the "wrong" license! your welcome. to All: Is it possible to have a talk with sun/oracle regarding this, are there contacts? Sun would have to allow for the use of that partly copy/pasted code under the EPL. Otherwise I am highly motivated to develop such an alternative fragment myself for the eclipse community. Not based on sun code but with some ideas of it. That would eliminate the license issue. But I would be glad if sun/oracle and eclipe - which is both JAVA! - would find a solution for these handful of java classes. From the deploy.jar which is approx 2MB of code only approx. 3% (50KB) is used.
just my 2 cent.... you be 10 times faster writing the code from scratch as you proposed than finding the "right" person at Sun who would have to agree to EPL code for Eclipse. Especially since it is now Sun/Oracle.... but again only my 2 cent (at most)
> just my 2 cent.... Ack. :-)
I opened a bug request at sun/oracle with a plain java hello world to reproduce (including the jwinhttp.dll). The bug request was now accepted and will soon appear at http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6967456
Hello Stefan and Ivan. I could not to reproduce on Vista 32 bit. Do I need to configure proxy connection in my OS to reproduce this bug?
(In reply to comment #34) > Hello Stefan and Ivan. I could not to reproduce on Vista 32 bit. Do I need to > configure proxy connection in my OS to reproduce this bug? Did you use the attached "Hello World" example? Do you have the possibility to test on windows 7?
> Did you use the attached "Hello World" example? Yes, I did. > Do you have the possibility to test on windows 7? I hope to I will have soon. However my question is still remaining: do I need to configure any proxy setting under my machine or "Hello World" example without any proxy configuration is enough?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.