Community
Participate
Working Groups
Build ID: 3.5 M5 Steps To Reproduce: Try to install something using the p2 engine: Thread [Thread-11] (Suspended) UnixProxyProvider.getGConfProxyInfo(String) line: not available [native method] ProxyProvider(UnixProxyProvider).getSystemProxyInfo(String) line: 166 ProxyProvider(UnixProxyProvider).getProxyForTypes(String[]) line: 69 ProxyProvider(UnixProxyProvider).getProxyData() line: 62 ProxyManager.getNativeProxyData() line: 182 ProxySelector.getProxyData(String) line: 66 ProxyType.getProxyData(String) line: 426 ProxyType.updateHttpSystemProperties() line: 382 ProxyType.updateSystemProperties(IProxyData) line: 211 ProxyType.initialize() line: 509 ProxyManager.initialize() line: 281 Activator.start(BundleContext) line: 179 BundleContextImpl$1.run() line: 807 AccessController.doPrivileged(PrivilegedExceptionAction<T>) line: not available [native method] BundleContextImpl.startActivator(BundleActivator) line: 798 BundleContextImpl.start() line: 779 BundleHost.startWorker(int) line: 352 BundleHost(AbstractBundle).start(int) line: 280 SecureAction.start(Bundle, int) line: 408 EclipseLazyStarter.postFindLocalClass(String, Class, ClasspathManager) line: 111 ClasspathManager.findLocalClass(String) line: 447 DefaultClassLoader.findLocalClass(String) line: 194 BundleLoader.findLocalClass(String) line: 376 SingleSourcePackage.loadClass(String) line: 33 BundleLoader.findClassInternal(String, boolean, ClassLoader) line: 440 BundleLoader.findClass(String, boolean) line: 405 BundleLoader.findClass(String) line: 393 DefaultClassLoader.loadClass(String, boolean) line: 88 DefaultClassLoader(ClassLoader).loadClass(String) line: 251 DefaultClassLoader(ClassLoader).loadClassInternal(String) line: 319 Class<T>.forName0(String, boolean, ClassLoader) line: not available [native method] Class<T>.forName(String) line: 169 Activator.getProxyService() line: 163 UrlConnectionRetrieveFileTransfer(AbstractRetrieveFileTransfer).setupProxies() line: 844 UrlConnectionRetrieveFileTransfer(AbstractRetrieveFileTransfer).sendRetrieveRequest(IFileID, IFileRangeSpecification, IFileTransferListener, Map) line: 776 UrlConnectionRetrieveFileTransfer(AbstractRetrieveFileTransfer).sendRetrieveRequest(IFileID, IFileTransferListener, Map) line: 477 MultiProtocolRetrieveAdapter.sendRetrieveRequest(IFileID, IFileTransferListener, Map) line: 95 ECFTransport.transfer(IRetrieveFileTransferContainerAdapter, String, OutputStream, IConnectContext, IProgressMonitor) line: 215 ECFTransport.performDownload(String, OutputStream, IConnectContext, IProgressMonitor) line: 164 ECFTransport.download(String, OutputStream, IProgressMonitor) line: 144 SimpleArtifactRepository.downloadArtifact(IArtifactDescriptor, URI, OutputStream, IProgressMonitor) line: 463 SimpleArtifactRepository.downloadArtifact(IArtifactDescriptor, OutputStream, IProgressMonitor) line: 446 SimpleArtifactRepository.getArtifact(IArtifactDescriptor, OutputStream, IProgressMonitor) line: 513 WRInstallAction.execute(Map) line: 45 ParameterizedProvisioningAction.execute(Map) line: 33 Install(Phase).mainPerform(MultiStatus, EngineSession, IProfile, Operand[], ProvisioningContext, SubMonitor) line: 116 Install(Phase).perform(MultiStatus, EngineSession, IProfile, Operand[], ProvisioningContext, IProgressMonitor) line: 62 InstallerThread$WRPhaseSet(PhaseSet).perform(ActionManager, EngineSession, IProfile, Operand[], ProvisioningContext, IProgressMonitor) line: 44 Engine.perform(IProfile, PhaseSet, Operand[], More information: This call never returns, not sure why though. I've seen several bugs regarind the gnome support in that area, but these were mostly crashes. My system is a RHEL5 x86_64 machine, with all the latest updates applied. My gtk version is 2.10.4
(In reply to comment #0) > <text deleted/> > This call never returns, not sure why though. I've seen several bugs regarind > the gnome support in that area, but these were mostly crashes. > My system is a RHEL5 x86_64 machine, with all the latest updates applied. My > gtk version is 2.10.4 > But the JVM is 32 bit, right?
(In reply to comment #1) > But the JVM is 32 bit, right? Hi Pawel :) Thanks for looking into this! Yeah, the jvm is 32bit, my application is started with -arch x86...
I'll try to reproduce the using available machines. In case I fail is it possible to access the machine the problem appears on? Moreover it looks similar to bug 257846 which has been closed because it was impossible to reproduce the problem.
Pawel, the machine is within our network, probably unreachable by you guys, but I can perform some tests if that helps. Is there any workaround I could try to bypass the problem for now?
(In reply to comment #4) > <text deleted/> > Is there any workaround I could try to bypass the problem for now? Sure, remove bundle org.eclipse.core.net.linux.x86 from your installation. And since there is a workaround I'm lowering the severity :)
This workaround works and is really easy to implement, thanks! :) Agreed, let's lower the priority! :) By the bye, just had a crash in the area insteaf the native call being stuck, unfortunately the shell died with the process so I've no backtrace :(
*** Bug 268471 has been marked as a duplicate of this bug. ***
I got this today while I was trying to refresh a file. Not sure what refreshing has to do with proxies, but anyway...
We don't have a machine to reproduce the problem. Since we're getting closer to 3.5 release and I doubt that such a machine will be available soon I'm moving the target to 3.6. If someone else encounters the problem and it's possible to access the host on which it happened please update the report.
(In reply to comment #9) I can run some tests for you if you tell me what to launch.. :)
(In reply to comment #10) > (In reply to comment #9) > I can run some tests for you if you tell me what to launch.. :) > Things to check probably include OS configuration and library dependencies. So, it's hard to come up with a set of tests that would expose the cause of the failure.
(In reply to comment #11) How about a shell script you write that does all the checks (ldd, rpm -qa, cat /etc/redhat-release, whatever) and I execute that script?
Helmut, what about investigating the issue on your own? Are you willing to create such a script? I could send you details about location of the code in Eclipse CVS repository. There you could check the native library sources and binaries as well.
(In reply to comment #13) Sounds good, I'd need some help in getting started though... ;)
Eclipse CVS repository: :pserver:dev.eclipse.org:/cvsroot/eclipse Projects to checkout: A) org.eclipse.core.net B) org.eclipse.core.net/fragments/org.eclipse.core.net.linux.x86 The first project contains the common proxy code and native sources. The second one only contains libgnomeproxy-1.0.0.so library. Please look at the native sources to find out what calls are being made. If you come up with a fix just rebuild the library, replace it and launch a self-hosted Eclipse (having projects A and B in your workspace).
At the beginning you could narrow the problem to the library itself and exclude JNI layer from the suspects.
One more thing, after having a look at the native code please dive into UnixProxyProvider class since all the calls to native Linux code are made from it. Hope that helps...
(In reply to comment #17) Thanks Pawel, I'll report back with my findings! :) Helmut
Alright, I looked into this for several hours now, here is what I found: - it's not our jni layer that causes the problems, it's gconf - gconf does not return from some calls, but does so sometimes as well.. - many times gconf won't even return from gconf_client_get_default - other times this initialization goes well but actual gconf_client_get_bool s won't return Also, the interesting thing is that standard gconftool-2 calls will always return successfully and return the right information as well. I'm thinking that maybe gconf's shutting itself down if no clients need it interfers here but that's plain guess work. So, I guess I'm stuck as much as Eclipse now, next steps would involve building and debugging gconf but I lack a good c-debugging solution that nicely integrates with jni and java, Pawel, do you have some pointers there as well?
(In reply to comment #19) > Alright, I looked into this for several hours now, here is what I found: > - it's not our jni layer that causes the problems, it's gconf > - gconf does not return from some calls, but does so sometimes as well.. > - many times gconf won't even return from gconf_client_get_default > - other times this initialization goes well but actual gconf_client_get_bool s > won't return > It's great you managed to narrow the problem. > Also, the interesting thing is that standard gconftool-2 calls will always > return successfully and return the right information as well. > > I'm thinking that maybe gconf's shutting itself down if no clients need it > interfers here but that's plain guess work. > If that's true could we check if the library has shut down and reinitialize it? What about gconftool-2, do you have any idea how it makes the calls? > So, I guess I'm stuck as much as Eclipse now, next steps would involve building > and debugging gconf but I lack a good c-debugging solution that nicely > integrates with jni and java, Pawel, do you have some pointers there as well? > Why do you need a tool that integrates with JNI and Java? Since the problem is with the library itself it's possible to debug the C code only, right? Anyway I don't know such a tool.
(In reply to comment #20) Q: If that's true could we check if the library has shut down and reinitialize it? A: I guess we could, but have not investigated in that direction.. Q: What about gconftool-2, do you have any idea how it makes the calls? A: That's where the time consuming tasks begin, I'd have to set up and use a c debugging environment with all the gconf sources... Q: Why do you need a tool that integrates with JNI and Java? Since the problem is with the library itself it's possible to debug the C code only, right? Anyway I don't know such a tool. A: Well, it would be so much more convenient to debug this from within eclipse, I'm also not sure how to debug a dll that's loaded into the jvm, gdb <path>/java or something more sophisticated? As you see, I'm eager to help but have my issues with the environment to get ready for debugging this...
(In reply to comment #21) > (In reply to comment #20) > <text deleted/> > I'm also not sure how to debug a dll that's loaded into the jvm, gdb > <path>/java or something more sophisticated? But the library doesn't have to be loaded in the JVM to cause the trouble, right? If that's true you could write a simple application in C that loads it and make the calls. > As you see, I'm eager to help but have my issues with the environment to get > ready for debugging this... > Anyway, you work got us closer to the solution. Thanks!
(In reply to comment #22) Re-hi Pawel :) Spent the last few hours creating my own executable and trying to reproduce things that way. Guess what, things work just fine in that environment. Neither the initialize call nor the actual retrieval of information is stuck when running my little .exe file, things are only reproducable using jni and java :( Also, this really looks like a timing issue, I now see three differing points of lock: 1.) The first call to gconf locks, gconf_client_get_default() 2.) A boolean retrieval fails after init went fine: gconf_client_get_bool(client, "/system/http_proxy/use_http_proxy", NULL); 3.) Once in all my tests things did not lock up at all, 4 complete passes of the jni code returned just fine Helmut
So it looks like JVM makes things hard. What about running the code in a different JVM?
(In reply to comment #24) > So it looks like JVM makes things hard. What about running the code in a > different JVM? > I'll try the newest SUN and IBM runtimes
(In reply to comment #25) Darn, neither SUNs 1.6.0_13 nur IBMs latest 60 improves the situation
Helmut, are all of the mentioned JVMs 32-bit?
(In reply to comment #27) > Helmut, are all of the mentioned JVMs 32-bit? > yep. My system is 64bit though, the jvms are thus using the 32bit compatibility support
What about using a 64-bit JVM? Native proxy support in Eclipse offers a binary for x86_64 which links to different OS libraries.
(In reply to comment #29) Pawel, I only found a 64 bit fragment for core.net.win32, is there one for linux as well? Also, my application only has 32bit fragments so that's why I'm using the setup I'm using...
(In reply to comment #30) > (In reply to comment #29) > Pawel, I only found a 64 bit fragment for core.net.win32, is there one for > linux as well? I'm sorry but I was convinced we do ship it for x86_64 too. I've opened bug 273072 to track the issue. > Also, my application only has 32bit fragments so that's why I'm using the setup > I'm using... > Right, I just wanted to narrow the problem more. I'm not sure what we could do now. Any suggestions?
(In reply to comment #31) Thanks for all your help Pawel, I'm not sure I can dig any deeper into this without looking at the gconf source. It just sucks that this freezes the entire application but I guess there is not much we can do about it, right?
If the native executable you've made makes the calls in the same fashion as we do in org.eclipse.core.net than yes, we can't do much. In such case I'll simply close the bug as NOT_ECLIPSE.
This bug manifests as a *hang*. I encounter this problem maybe once in 10 tries on my machine. That's the worst kind of failure. It hangs in different places. Having a random hang near startup is a huge and unacceptable problem, and I can't believe we are considering shipping a release with this. This sort of thing really hurts the adoption of Eclipse. I know something about this bug, as I caused it. There are other bug reports related to this that document the whole story, but as far as I know my recommendations for the correct solution to this problem have never been followed. 1) This bug is caused by a hang in native code used to get the Gnome proxy configuration to allow the proxy information to be automatically set. This was added late in the 3.4 release cycle, and I did the original implementation. The native code has always had problems. 2) If you consider a tradeoff between the functionality of getting the proxy information from the Gnome and having random hangs, I think the right answer is to simply disable the getting of the proxy implementation. This should be done for 3.5. The value of getting it from Gnome is questionable in the first place (I only wrote the original code as a favor to Syzmon). 3) The current implementation of the native library is done using normal dynamic shared library binding, but then the calls are done through the normal C call mechanism. The Sun JRE contains an implementation of this that uses not only dynamic binging, but a dynamic calling mechanism (this was the implementation that inspired my implementation, however I did not use the dynamic calls -- and we have all paid the price). I belive the correct solution is to adopt the way the Sun JRE works. That should be done in 3.6. Here is another example, this happens on my Fedora 10 system. Versions: main /d/build/transform/build> rpm -q gtk+ gtk+-1.2.10-66.fc10.x86_64 main /d/build/transform/build> rpm -q gtk2 gtk2-2.14.7-7.fc10.x86_64 gtk2-2.14.7-7.fc10.i386 Full thread dump Java HotSpot(TM) Client VM (11.2-b01 mixed mode, sharing): "MultiThreadedHttpConnectionManager cleanup" daemon prio=10 tid=0x095df000 nid=0x3970 in Object.wait() [0x023b6000..0x023b7120] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb30615c0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0xb30615c0> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at org.apache.commons.httpclient.MultiThreadedHttpConnectionManager$ReferenceQueueThread.run(MultiThreadedHttpConnectionManager.java:1122) "Thread-3" daemon prio=10 tid=0xf6ff7000 nid=0x396e in Object.wait() [0x027d7000..0x027d8020] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb30618e0> (a org.apache.commons.httpclient.util.IdleConnectionTimeoutThread) at org.apache.commons.httpclient.util.IdleConnectionTimeoutThread.run(IdleConnectionTimeoutThread.java:108) - locked <0xb30618e0> (a org.apache.commons.httpclient.util.IdleConnectionTimeoutThread) "Worker-6" prio=10 tid=0xf6e1c400 nid=0x3969 in Object.wait() [0x01f03000..0x01f03ea0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185) - locked <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51) "Worker-5" prio=10 tid=0x09ec3400 nid=0x3968 waiting for monitor entry [0x071b9000..0x071baf20] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:464) - waiting to lock <0xb0ecb0c8> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:445) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:449) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) - locked <0xb200c2d8> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:621) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:183) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:576) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:546) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:477) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:465) - locked <0xb200c2d8> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:445) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:452) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:321) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:231) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1193) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:874) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.ui.internal.WorkbenchPlugin$1.run(WorkbenchPlugin.java:267) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:52) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:263) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition$1.run(LightweightDecoratorDefinition.java:124) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.core.runtime.Platform.run(Platform.java:888) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.internalGetDecorator(LightweightDecoratorDefinition.java:120) at org.eclipse.ui.internal.decorators.LightweightDecoratorDefinition.decorate(LightweightDecoratorDefinition.java:251) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager$LightweightRunnable.run(LightweightDecoratorManager.java:81) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.decorate(LightweightDecoratorManager.java:365) at org.eclipse.ui.internal.decorators.LightweightDecoratorManager.getDecorations(LightweightDecoratorManager.java:347) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.ensureResultCached(DecorationScheduler.java:371) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(DecorationScheduler.java:331) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "Worker-4" prio=10 tid=0x0956b400 nid=0x3967 in Object.wait() [0x084e3000..0x084e3da0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185) - locked <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51) "Worker-3" prio=10 tid=0x0956d800 nid=0x3966 in Object.wait() [0x073f8000..0x073f8e20] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185) - locked <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51) "Worker-2" prio=10 tid=0x09570000 nid=0x3965 in Object.wait() [0x0163e000..0x0163f0a0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:185) - locked <0xaf671240> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:217) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:51) "Java indexing" daemon prio=10 tid=0xf7313400 nid=0x3963 in Object.wait() [0x0525b000..0x0525c120] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb1331968> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager) at java.lang.Object.wait(Object.java:485) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobManager.java:378) - locked <0xb1331968> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager) at java.lang.Thread.run(Thread.java:619) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=10 tid=0xf6f50000 nid=0x3962 in Object.wait() [0x01a9c000..0x01a9cfa0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb146fe10> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:179) - locked <0xb146fe10> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=10 tid=0x09d22000 nid=0x3960 in Object.wait() [0x01e02000..0x01e03020] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb1254a48> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:179) - locked <0xb1254a48> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) "org.eclipse.jface.text.reconciler.MonoReconciler" daemon prio=10 tid=0x0955cc00 nid=0x395f in Object.wait() [0x0199b000..0x0199bea0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb1125930> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:179) - locked <0xb1125930> (a org.eclipse.jface.text.reconciler.DirtyRegionQueue) "Bundle File Closer" daemon prio=10 tid=0x09c8b400 nid=0x395e in Object.wait() [0x0189a000..0x0189af20] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb1125940> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:386) - locked <0xb1125940> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:326) "[ThreadPool Manager] - Idle Thread" daemon prio=10 tid=0x0972a000 nid=0x395d in Object.wait() [0x01c9b000..0x01c9bda0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xb1028cd8> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor) at java.lang.Object.wait(Object.java:485) at org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor.run(Executor.java:106) - locked <0xb1028cd8> (a org.eclipse.equinox.internal.util.impl.tpt.threadpool.Executor) "Worker-0" prio=10 tid=0x0909ec00 nid=0x3953 runnable [0x07f86000..0x07f89020] java.lang.Thread.State: RUNNABLE at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getGConfProxyInfo(Native Method) at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getSystemProxyInfo(UnixProxyProvider.java:166) at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getProxyForTypes(UnixProxyProvider.java:69) at org.eclipse.core.internal.net.proxy.unix.UnixProxyProvider.getProxyData(UnixProxyProvider.java:62) at org.eclipse.core.internal.net.ProxyManager.getNativeProxyData(ProxyManager.java:182) at org.eclipse.core.internal.net.ProxySelector.getProxyData(ProxySelector.java:91) at org.eclipse.core.internal.net.ProxyType.getProxyData(ProxyType.java:426) at org.eclipse.core.internal.net.ProxyType.updateHttpSystemProperties(ProxyType.java:382) at org.eclipse.core.internal.net.ProxyType.updateSystemProperties(ProxyType.java:211) at org.eclipse.core.internal.net.ProxyType.initialize(ProxyType.java:509) at org.eclipse.core.internal.net.ProxyManager.initialize(ProxyManager.java:281) at org.eclipse.core.internal.net.Activator.start(Activator.java:179) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:782) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:773) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:754) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:408) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:449) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) - locked <0xb0ee1a68> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.eclipse.jsch.internal.core.JSchCorePlugin.start(JSchCorePlugin.java:161) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:782) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:773) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:754) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:408) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:449) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) - locked <0xb0ecb0c8> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.eclipse.team.internal.ccvs.core.CVSProviderPlugin.start(CVSProviderPlugin.java:308) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:782) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:773) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:754) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352) at org.eclipse.osgi.framework.internal.core.AbstractBundle.start(AbstractBundle.java:280) at org.eclipse.osgi.framework.util.SecureAction.start(SecureAction.java:408) at org.eclipse.core.runtime.internal.adaptor.EclipseLazyStarter.postFindLocalClass(EclipseLazyStarter.java:111) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:449) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:452) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at org.eclipse.osgi.internal.loader.BundleLoader.loadClass(BundleLoader.java:321) at org.eclipse.osgi.framework.internal.core.BundleHost.loadClass(BundleHost.java:231) at org.eclipse.osgi.framework.internal.core.AbstractBundle.loadClass(AbstractBundle.java:1193) at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:160) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:874) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51) at org.eclipse.team.core.RepositoryProvider.newProvider(RepositoryProvider.java:706) at org.eclipse.team.core.RepositoryProvider.mapNewProvider(RepositoryProvider.java:162) at org.eclipse.team.core.RepositoryProvider.mapExistingProvider(RepositoryProvider.java:235) at org.eclipse.team.core.RepositoryProvider.getProvider(RepositoryProvider.java:507) at org.eclipse.team.internal.core.TeamHookDispatcher.getProvider(TeamHookDispatcher.java:97) at org.eclipse.team.internal.core.TeamHookDispatcher.getRuleFactory(TeamHookDispatcher.java:105) at org.eclipse.core.internal.resources.Rules.factoryFor(Rules.java:92) at org.eclipse.core.internal.resources.Rules.refreshRule(Rules.java:157) at org.eclipse.core.internal.resources.Resource.refreshLocal(Resource.java:1512) at org.eclipse.core.internal.refresh.RefreshJob.runInWorkspace(RefreshJob.java:166) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) "[Timer] - Main Queue Handler" daemon prio=10 tid=0x0925cc00 nid=0x3950 in Object.wait() [0x0153d000..0x0153dea0] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf71e078> (a java.lang.Object) at org.eclipse.equinox.internal.util.impl.tpt.timer.TimerImpl.run(TimerImpl.java:141) - locked <0xaf71e078> (a java.lang.Object) at java.lang.Thread.run(Thread.java:619) "Framework Event Dispatcher" daemon prio=10 tid=0x0912d800 nid=0x394d in Object.wait() [0x08604000..0x08604da0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf63c200> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:386) - locked <0xaf63c200> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:326) "Start Level Event Dispatcher" daemon prio=10 tid=0x09132c00 nid=0x394c in Object.wait() [0x0143c000..0x0143ce20] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf6367d0> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at java.lang.Object.wait(Object.java:485) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent(EventManager.java:386) - locked <0xaf6367d0> (a org.eclipse.osgi.framework.eventmgr.EventManager$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:326) "State Data Manager" daemon prio=10 tid=0x090e7000 nid=0x394b waiting on condition [0x0133b000..0x0133c0a0] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.eclipse.osgi.internal.baseadaptor.StateManager.run(StateManager.java:306) at java.lang.Thread.run(Thread.java:619) "Low Memory Detector" daemon prio=10 tid=0xf7c02400 nid=0x3949 runnable [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0xf7c00800 nid=0x3948 waiting on condition [0x00000000..0x00f81ad8] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x09096000 nid=0x3947 waiting on condition [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=10 tid=0x09091000 nid=0x3946 in Object.wait() [0x06dcc000..0x06dccf20] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf4b13d8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0xaf4b13d8> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x0908c400 nid=0x3945 in Object.wait() [0x010b8000..0x010b8da0] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0xaf4b1460> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0xaf4b1460> (a java.lang.ref.Reference$Lock) "main" prio=10 tid=0x09063800 nid=0x3936 waiting for monitor entry [0xffef2000..0xffef39e8] java.lang.Thread.State: BLOCKED (on object monitor) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:464) - waiting to lock <0xb200c2d8> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:445) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:211) at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:376) at org.eclipse.osgi.internal.loader.SingleSourcePackage.loadClass(SingleSourcePackage.java:33) at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:449) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105) at java.lang.ClassLoader.loadClass(ClassLoader.java:252) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320) - locked <0xb1f99318> (a org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader) at org.eclipse.mylyn.internal.team.ccvs.CvsActiveChangeSetProvider.getActiveChangeSetManager(CvsActiveChangeSetProvider.java:26) at org.eclipse.mylyn.internal.team.ui.FocusedTeamUiPlugin.addActiveChangeSetProvider(FocusedTeamUiPlugin.java:128) at org.eclipse.mylyn.internal.team.ui.FocusedTeamExtensionPointReader.readExtensions(FocusedTeamExtensionPointReader.java:55) at org.eclipse.mylyn.internal.team.ui.FocusedTeamUiPlugin$1.run(FocusedTeamUiPlugin.java:81) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:134) - locked <0xb1f9ff10> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3460) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3107) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2405) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2369) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2221) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:500) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:493) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:194) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:368) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:559) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:514) at org.eclipse.equinox.launcher.Main.run(Main.java:1311) "VM Thread" prio=10 tid=0x0908a800 nid=0x3944 runnable "VM Periodic Task Thread" prio=10 tid=0x09098c00 nid=0x394a waiting on condition JNI global references: 1318 Heap def new generation total 5760K, used 2145K [0xace00000, 0xad430000, 0xaf470000) eden space 5184K, 30% used [0xace00000, 0xacf88740, 0xad310000) from space 576K, 100% used [0xad3a0000, 0xad430000, 0xad430000) to space 576K, 0% used [0xad310000, 0xad310000, 0xad3a0000) tenured generation total 74936K, used 64882K [0xaf470000, 0xb3d9e000, 0xcc200000) the space 74936K, 86% used [0xaf470000, 0xb33ccb20, 0xb33ccc00, 0xb3d9e000) compacting perm gen total 36864K, used 36647K [0xcc200000, 0xce600000, 0xd4200000) the space 36864K, 99% used [0xcc200000, 0xce5c9ce0, 0xce5c9e00, 0xce600000) ro space 8192K, 74% used [0xd4200000, 0xd47f80d8, 0xd47f8200, 0xd4a00000) rw space 12288K, 58% used [0xd4a00000, 0xd5113618, 0xd5113800, 0xd5600000)
One more thing, it happened in the comment above in Build id: I20090508-2000
(In reply to comment #34) Thanks Francis for the remark. That's weird that we have a blocker since 3.4 and we have this comment at the end of 3.5. The code has been improved since 3.4 and has been tested on many configurations. Before we disable the code, Pawel will look at it and answer comment 34. I believe that Pawel would need access to the box where Eclipse fails. Francis could you give him a hand? > but as far as I know my > recommendations for the correct solution to this problem have never been > followed. Please elaborate.
(In reply to comment #36) > (In reply to comment #34) > Thanks Francis for the remark. That's weird that we have a blocker since 3.4 > and we have this comment at the end of 3.5. > I have encountered this hang several times, and I have reported it previously at least once: https://bugs.eclipse.org/bugs/show_bug.cgi?id=268471 I assumed that it would be fixed before 3.5 or disabled, so when I hit it again today I was pretty alarmed. > I believe that Pawel would need access to the box where Eclipse fails. Francis > could you give him a hand? I'm not in a position right now to allow remote access to my computer. However, it's a pretty standard setup, 64-bit Fedora 10 system running on an Intel PC, kept up to date with the latest updates. I'm running a 32-bit JVM. > Please elaborate. I'm not sure what more to say; from the beginning I have advocated replacing my code as I describe in item 3 in comment 34, as that's what the JVM does, and I assume that the JVM way works. I'm sorry that I don't have any time to work on this, as I barely have enought time to deal with my CNF responsibilities.
In the absence of a real fix for the problem (and even full understanding what is causing it), I see three options given how late we are: 1. Remove the functionality 2. Remove the functionality if we detect a 32 bit VM on a 64 bit machine (is this doable?) 2. Ship with the bug but document the workaround in the readme file. I am not sure which option is best. Any opinions?
(In reply to comment #38) > 1. Remove the functionality > 2. Remove the functionality if we detect a 32 bit VM on a 64 bit machine (is > this doable?) Have we proven or explained that this problem only exists on 64-bit systems? If that's not the case, I don't think we should consider this alternative. > 2. Ship with the bug but document the workaround in the readme file. Speaking as an RCP application provider, this would make the 3.5 unusable for me. I cannot ship an application which randomly hangs. At this point I would say we need to turn this off. I don't think we can afford to ship a system where there is any known possibility of a hang that occurs with any regularity.
For the record, it will hang on my computer which runs on 32-bit Gentoo Linux (see comment 8). We've shipped other hanging problems in the past (GTK+ printer problem, which hangs Eclipse for anywhere from 15 seconds to "eternity"). How ironic it is that that's been worked around (per se) and we now have another hanging problem. Of course, both that and this problem has workarounds.
For those that don't know, the printer bug is a problem in GTK+'s code. I suppose this is a similar case where the hang is in GNOME code.
(In reply to comment #39) > Have we proven or explained that this problem only exists on 64-bit systems? > If that's not the case, I don't think we should consider this alternative. Right - after seeing Remy's comment that it happens on his 32 bit machine as well, this option can be ruled out. > > 2. Ship with the bug but document the workaround in the readme file. > Speaking as an RCP application provider, this would make the 3.5 unusable for > me. I cannot ship an application which randomly hangs. You could ship your app without org.eclipse.core.net.linux.x86, couldn't you? Then again, we could ship the Eclipse SDK without the fragment, too... Is there anything else in org.eclipse.core.net.linux.x86 that we need, or is this fragment's only purpose to get proxy information from Gnome? Do we know of any products that rely on the presence of this fragment?
(In reply to comment #42) > (In reply to comment #39) > Then again, we could ship the Eclipse SDK without the fragment, too... Is there > anything else in org.eclipse.core.net.linux.x86 that we need, or is this > fragment's only purpose to get proxy information from Gnome? Do we know of any > products that rely on the presence of this fragment? > There is a switch to turn the loading of the native proxy provider off (we used it in 3.4). It's very easy. And even if others are using this to get the gnome proxy configuration, it should still be turned off because it's broken.
I have been hitting this pretty consistently today self hosting when I have CDT, WST and several CVS projects in my workspace.
(In reply to comment #34) > The current implementation of the native library is done using normal > dynamic shared library binding, but then the calls are done through the normal > C call mechanism. The Sun JRE contains an implementation of this that uses not > only dynamic binging, but a dynamic calling mechanism (this was the > implementation that inspired my implementation, however I did not use the > dynamic calls -- and we have all paid the price). Thanks for pointing the direction. I have to say that this is the first time I see this solution manifested. I'll investigate on the possible fix. > I belive the correct solution is to adopt the way the Sun JRE works. What about other JVMs?
My vote is leave the code in, but have it disabled by default. This is the only fix that makes sense this late in the cycle, particularly since we can't seem to repeat it locally.
(In reply to comment #45) > I'll investigate on the possible fix. Francis, what is the connection between using dynamic calling mechanism and avoiding the hung? I managed to find bug 232495, comment 19 and it seems that the solution was proposed to overcome linking issues. In this case linking works fine and we don't have a problem with finding the right method to call, right? Moreover linking problems that occurred earlier in the cycle seem to have disappeared after bug 232495 got fixed.
(In reply to comment #47) > (In reply to comment #45) > > I'll investigate on the possible fix. > > Francis, what is the connection between using dynamic calling mechanism and > avoiding the hung? I don't know. I'm just making the assumption that the Sun JVM implementation actually works reliably, and it uses a dynamic calling method, so that's what we should do. However, that assumtion that the Sun JVM actually *does* work reliably is just that, an assumption. Maybe it has the same hang problems that we are having. I have not investigated Sun's implementation is any better than what we have.
> > I belive the correct solution is to adopt the way the Sun JRE works. > > What about other JVMs? > I'm not sure I understand your question. What I'm proposing is independent from which JVM we are using, I'm only saying we should code it the way the Sun JVM does it. But again, as in the earlier comment, I'm making an assumption that the Sun folks know what their doing. I could be wrong about that.
(In reply to comment #46) > My vote is leave the code in, but have it disabled by default. +1, and this is easy
We're adding the property similar to disablePrinters.
Created attachment 136775 [details] Patch_v01 A patch disabling GNOME support. To enable it user has to run eclipse with "-Dorg.eclipse.core.net.enableGnomeSupport" switch.
Created attachment 136796 [details] Patch_v02 Minor update, I changed the switch to be "-Dorg.eclipse.core.net.enableGnome".
Grant or Remy could give another +1.
I've opened bug 277440 to track the cause of the problem. If we hunt it down proxy support for GNOME will be enabled in 3.6.
I've reviewed the patch (but not run it) and am happy with it.
Released to HEAD.
Seems like something that should be added to the readme.
(In reply to comment #58) > Seems like something that should be added to the readme. > Sure, I've opened bug 277484 to make sure it goes into RC3.
Verified in 3.5RC3
