Community
Participate
Working Groups
Build Identifier: 20110615-0604 When I attempt to start the Geronimo server from inside Eclipse, 4 out of 5 tries, the ui hangs trying to start the server. I can still edit files and the UI is responsive, but the Geronimo server process is not started and the Console View's console display becomes greyed with the message "No consoles to display at this time." (pre-server launch state, I suppose.) My only option to getting the UI unstuck is to stop and restart eclipse to try starting the server again. (Eclipse typically has not continued to hang up during the shutdown procedure as part of this bug and I don't have to force kill the process.) I think my problem is related to my mix of plugins, and something intermittently grabbing a resource from (I suspect) the debug ui, keeping it from proceeding far enough to allow my server to start. I only started to get this error with the Indigo Eclipse release, previous Eclipse releases with a similar plugin mix did not exhibit this behavior. Typically, there is nothing in the log that I perceive directly coincides with the hang. But today I actually got an interesting warning in the eclipse log, which prompted me to file this bug. (See debuguierrors.txt) I typically have other warnings and errors in the log that appear at eclipse startup and do, these may be related to the hang as well. (See startuperrors.txt and suspectmessages.txt) I have the Geronimo Eclipse Plugin version 2.1.6 installed. I also have mylyn, Spring IDE 2.7.1.201107082359-RELEASE, ZeroTurnaround's JRebel Eclipse Plugin 1.4.8.201107252119, and the Eclipse Modeling Project (papyrus 0.8.0.v201106151827) installed. Reproducible: Sometimes Steps to Reproduce: 1. start eclipse 2. click debug or start button on Servers View with my Geronimo server selected (no other 3. intermittent hang inside eclipse preventing the Geronimo java process from launching
Created attachment 203025 [details] rare error (never noticed before) that I believe coincides with my hang
Created attachment 203026 [details] errors I typically see during the eclipse startup in my logs
Created attachment 203027 [details] messages that may or may not be relevant to my bug that appear during eclipse startup in the logs
Further important details I forgot to mention: I do notice sometimes the Console View does transition to viewing the geronimo server logs (the display area turns blank white from gray). Also, when this happens, the Progress View gets to 23% "Establishing debug connection..." There actually is a Geronimo server java process that is started in this case, but I believe that it is suspended by Eclipse? When I try to click over to the Debug Perspective, the entire Eclipse UI hangs!
Additional discovery just made (sorry for not noticing sooner): Starting from a freshly started eclipse -clean, clicking on Debug perspective without doing anything with Geronimo, got a complete Eclipse UI hang! Restarted, deleted Geronimo server from the Servers view, clicked Debug perspective, complete Eclipse UI hang! Restarted with a blank, new workspace, clicked Debug perspective, no hang! Looking at what is odd about my workspace, I see I have a 32bit JRE in my java Installed JRE's list (My workstation is a 64-bit Windows 7.) I was not using that JRE except to start geronimo (since my target environment was 32-bit). Deleted the 32bit JRE from my Installed JRE's list. Restarted Eclipse. Clicked on Debug perspective, still got a hang... I used jvisualvm to take a thread dump, hopefully someone in the know can identify what the deadlock is. (See attachment debugperspectivehang_threaddump.txt)
Created attachment 203029 [details] thread dump for when Debug Perspective hangs the Eclipse UI
(In reply to comment #6) > Created attachment 203029 [details] > thread dump for when Debug Perspective hangs the Eclipse UI The "main" thread is runnable and is trying to allocate a new object. Maybe your host Eclipse (the one that hangs) just doesn't have enough memory, and it hangs due to GC overhead. You're running with a 64-bit VM, so pointers may use more memory. Does the Eclipse process use a lot of CPU? Even if the Geronimo server doesn't come up for any reason, that shouldn't block the host Eclipse. Moving to Debug.
Hi Markus Keller, thanks for looking at my bug. I believe I have narrowed the issue since I was able to reproduce it without Geronimo Eclipse Plugin in the mix. First of all to your CPU question, there is no CPU utilization when the entire Eclipse hangs. So nothing is spinning trying to get a lock, just some master lock must be grabbed? System memory does not appear to be an issue nor change when I induce a hang. I have narrowed my bug to eclipse's breakpoints system. If I have breakpoints set in my workspace, *specifically against JavaScript source files*, then I can reproduce the UI hang when trying to switch to the Debug perspective and I can reproduce the intermittent Geronimo server startup hang. I can manipulate the breakpoints without inducing a hang by bringing just the breakpoints view into my Javascript perspective. If I delete all Javascript source breakpoints, then I can transition to the Debug perspective and start Geronimo from Eclipse without incident. If I return to the JavaScript perspective, recreate the javascript file breakpoints, close the Breakpoints view, restart Eclipse, and try to transition to the Debug perspective, I can get the UI hang again. So, there's something ELSE (not the Breakpoints view, specifically) in the Debug perspective or debug UI that is hanging up on Javascript breakpoints. Also, my hang scenario must occur against a fresh Eclipse. For example, if I'm ever able to transition to the Debug perspective or even startup with the Breakpoints view showing in the JavaScript perspective, then I'm never hung up when transitioning to the Debug perspective for that session, regardless of what breakpoints I set. Just to add information, I do not do any Javascript debugging in Eclipse and have configured no JS runtime for debugging as such. The breakpoints I had set that caused all my hangs must have been due to errant clicks in the editor throughout routine editing of my js files. And because breakpoints persist with the workspace, I was left with a hobbled system until I realized I needed to clear those breakpoints...
(In reply to comment #8) > Hi Markus Keller, thanks for looking at my bug. I believe I have narrowed the > issue since I was able to reproduce it without Geronimo Eclipse Plugin in the > mix. > Looking at the trace, it looks like this bug is a dupe of bug 345298 - the "Remove All Breakpoints" action is trying compute its enabled state and JSDT is trying to set its "Suspend on Exception" breakpoint. *** This bug has been marked as a duplicate of bug 345298 ***
