Bugzilla – Full Text Bug Listing
| Summary: | Livelock on startup | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jeff McAffer <jeffmcaffer> |
| Component: | SWT | Assignee: | Platform-SWT-Inbox <platform-swt-inbox> |
| Status: | CLOSED WORKSFORME | QA Contact: | |
| Severity: | major | ||
| Priority: | P3 | CC: | dj.houghton, lshanmug, markus.kell.r, remy.suen, skovatch |
| Version: | 3.7 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Jeff McAffer
I've had some luck reproducing by starting Eclipse and then clicking the Browse button in the workspace chooser *before* that stack trace appears (seems like in the first 5 seconds or so). The file chooser opens but then I get the lockup. I just tried another theory. Start Eclipse and then drop down the previous workspace list and don't pick anything, just leave it dropped down. When that timeout happens and the stacktrace appears, one core will get saturated. I seem to be able to reproduce this all the time. Please try upgrading to a newer build, Jeff. *** This bug has been marked as a duplicate of bug 330373 *** I am able to reproduce this problem with the same build (i1116 32bit version) on my Mac. I start up Eclipse, open up the "previous workspace" drop down, don't select anything, wait a few (30?) seconds, (I actually went to another app and then back later) then you get the "beachball of death". (as Jeff refers to it :-) I tried these steps with the 1130 i-build though and don't get the livelock. I think the stack trace is a red herring. Maybe there was a change in SWT here? I *think* the drop-down remained open when I switched apps in the i1116 build but when I switch apps in the i1130 build it closes when losing focus. Maybe someone in SWT can comment/close. When you say "the drop-down", do you mean the sub-menu of "File > Switch Workspace", or do you mean the Combo in the "Switch Workspace > Others..." dialog? If it's the former, then the problem could also be in Platform UI, near bug 244316 comment 18 (but it's not that bug). I'm starting Eclipse from the command-line (not doing a switch workspace) so it is the combo/dropdown/thingie that allows me to choose a recently used workspace. (In reply to comment #3) > I am able to reproduce this problem with the same build (i1116 32bit version) > on my Mac. I start up Eclipse, open up the "previous workspace" drop down, > don't select anything, wait a few (30?) seconds, (I actually went to another > app and then back later) then you get the "beachball of death". (as Jeff refers > to it :-) > > I tried these steps with the 1130 i-build though and don't get the livelock. > > I think the stack trace is a red herring. Maybe there was a change in SWT here? > I *think* the drop-down remained open when I switched apps in the i1116 build > but when I switch apps in the i1130 build it closes when losing focus. I've been doing some work with fixing focus saving/restoration lately, so it's very possible that I fixed this. See bug 330749. I just fixed it on 11/29, though, so I don't think it would have made it into an 11/30 I-build. I could be wrong, though. The combo box should close when the window deactivates. Actually, just about any click that isn't on the combo box should hide the drop-down menu. Jeff (or anyone else who can reproduce this), are you using Mac OS X 10.6 or 10.5.x? See bug 330345. I am using 10.6.5. 10.6.5 here too. This does look like it could be a dupe of the other bug... Aha! I think I just figured this out, looking at the native samples in 330345. Clicking outside the popup or switching to another application _should_ trigger something inside AppKit so that the combo box's popup window can be hidden. But when a Java exception is thrown JNI is basically hosed at that point, so no callbacks into the SWT will fire, including calls that AppKit is relying on to keep event dispatch going. So, we end up stuck in a tight loop. Let me try to reproduce this again and I'll try to confirm the theory. sounds promising. I will just point out that I don't need to click outside. Just drop down the combo. My naive theory was that this triggers another event loop to manage the dropdown action and then the exception happens and ... (as you say). This is reproducible every time for me. (In reply to comment #11) > sounds promising. I will just point out that I don't need to click outside. > Just drop down the combo. My naive theory was that this triggers another event > loop to manage the dropdown action and then the exception happens and ... (as > you say). This is reproducible every time for me. Yep, you are exactly right. Dropping down the combo box should be enough -- eventually a timer will fire and execute the offending line of code. The trick, I guess, is showing the combo box popup menu quickly enough to trigger it. 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. Closing, please reopen if problem still happens with latest eclipse. |