Community
Participate
Working Groups
Created attachment 266754 [details] Secure storage dialog promts for a password After starting a workspace, when I do a right-click on an existing project, Eclipse (Neon.2) freezes on my Ubuntu (16.04 LTS) system i. e. the context menu does not open and Eclipse does not react on input anymore. The freeze lasts serveral minutes. When I disable the internet connection before loading a workspace then I can perform a right-click as usual. Right after the right-click, a "Secure storage" dialog promts for a password (see attached image). After entering the password the context menu opens and everything works - even when I enable my internet connection afterwards.
(In reply to Nicolas Peifer from comment #0) > Created attachment 266754 [details] > Secure storage dialog promts for a password > > After starting a workspace, when I do a right-click on an existing project, In which view? Please take some stack traces, so that we can see where it hangs.
I perform a right-click on the project in the project explorer. I will attach an excerpt from the .metadata/.log file. I don't know how to obtain a stacktrace as no hs_err*.log is in my home folder.
Created attachment 266781 [details] Excerpt from workspace/.metadata/.log of a session that freezed
(In reply to Nicolas Peifer from comment #2) > I don't know how to obtain a > stacktrace as no hs_err*.log is in my home folder. See https://wiki.eclipse.org/How_to_report_a_deadlock
Created attachment 266810 [details] Thread dump
(In reply to Nicolas Peifer from comment #5) > Created attachment 266810 [details] > Thread dump Some people seem to do too much work during menu creation: at org.eclipse.core.internal.jobs.Semaphore.acquire(Semaphore.java:39) - locked <0x00000000ca26c868> (a org.eclipse.core.internal.jobs.Semaphore) ... at org.eclipse.ecf.provider.filetransfer.httpclient4.HttpClientRetrieveFileTransfer.openStreams(HttpClientRetrieveFileTransfer.java:626) ... at org.eclipse.equinox.internal.p2.transport.ecf.RepositoryTransport.stream(RepositoryTransport.java:172) at org.eclipse.oomph.p2.internal.core.CachingTransport.stream(CachingTransport.java:261) ... at org.springsource.ide.eclipse.commons.internal.core.net.P2TransportService.stream(P2TransportService.java:139) ... at org.springframework.ide.eclipse.boot.ui.EnableDisableBootDevtools.<init>(EnableDisableBootDevtools.java:54) ... at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:184) at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:905) at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243) at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:55) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension(WorkbenchPlugin.java:282) at org.eclipse.ui.internal.PluginAction.createDelegate(PluginAction.java:122) ... at org.eclipse.ui.internal.PopupMenuExtender.menuAboutToShow(PopupMenuExtender.java:394) I.e., while you are waiting for the menu, "everybody" seems to see an urgent need to initialize "everything", leading to some (slow?) network access. From a glance at this stack, I'd first suspect org.springframework.ide of doing too much during initialization. Not sure if oomph's role in this stack is "good" or "bad".
Can this problem be reproduced without STS installed?
*** This bug has been marked as a duplicate of bug 511941 ***
