| Summary: | SVN blocks all activity, effectively hanging the full IDE | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Technology] Subversive | Reporter: | Sarah Gerweck <tacpub> | ||||
| Component: | Core | Assignee: | Igor Burilo <igor.burilo> | ||||
| Status: | RESOLVED NOT_ECLIPSE | QA Contact: | |||||
| Severity: | critical | ||||||
| Priority: | P3 | CC: | a.gurov, svdbg | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Sarah Gerweck
Hello, Could you please: 1) specify Subversive and Subversive connectors version 2) attach a thread dump, captured when threads are blocked. There is a guideline about how to capture a stack trace when deadlock is occured: http://wiki.eclipse.org/How_to_report_a_deadlock Created attachment 203549 [details]
Frozen Eclipse stack dump
I (unfortunately) managed to experience another instance where SVN blocked my entire JVM. It wasn't exactly the same use case, but the symptoms were the same: some SVN activity sits forever, and ignores any effort to cancel it. This brings down the entire IDE, which must be killed. This time it corrupted my workbench, so I had to reconfigure my perspectives. This is really a *terrible* bug. I've attached the jstack. My installed versions: Subversive SVN Connectors 2.2.2.I20110602-1700 org.polarion.eclipse.team.svn.connector.feature.group Polarion Software Subversive SVN Integration for the Mylyn Project (Optional) (Incubation) 0.7.9.I20110602-1700 org.eclipse.team.svn.mylyn.feature.group Eclipse.org Subversive SVN JDT Ignore Extensions (Optional) (Incubation) 0.7.9.I20110602-1700 org.eclipse.team.svn.resource.ignore.rules.jdt.feature.group Eclipse.org Subversive SVN Team Provider (Incubation) 0.7.9.I20110602-1700 org.eclipse.team.svn.feature.group Eclipse.org SVNKit 1.3.5 Implementation (Optional) 2.2.2.I20110602-1700 org.polarion.eclipse.team.svn.connector.svnkit16.feature.group Polarion Software Hello, I don't succeed to launch Eclipse Helios : the splash screen halts when trying the load the Subversive GUI (org.eclipse.team.svn.ui). I installed Subversion yesterday, but I've been able to start Eclipse several times without any problem. It seems the problem occurs because I switch off my system yesterday when leaving the office, and boot it today. I can't tell you the exact release I use, but I installed the last release of Helios one week ago, and grab Subversion from the Helios depository. I chose the last releases of connectors and others. I am on CentOS 5.5, and I use Java 1.6.0.27. Please don't tell me to use Indigo : it has some problems with CDT. Hello,
I don't succeed to launch Eclipse Helios : the splash screen halts when trying the load the Subversive GUI (org.eclipse.team.svn.ui). I installed Subversion yesterday, but I've been able to start Eclipse several times without any problem. It seems the problem occurs because I switch off my system yesterday when leaving the office, and boot it today.
I can't tell you the exact release I use, but I installed the last release of Helios one week ago, and grab Subversion from the Helios depository. I chose the last releases of connectors and others.
I am on CentOS 5.5, and I use Java 1.6.0.27.
Please don't tell me to use Indigo : it has some problems with CDT.
Here is the trace with eclipse -vm java -vmargs -XX:+HeapDumpOnOutOfMemoryError :
Exception in thread "Thread-0" org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:4083)
at org.eclipse.swt.SWT.error(SWT.java:3998)
at org.eclipse.swt.SWT.error(SWT.java:3969)
at org.eclipse.swt.widgets.Widget.error(Widget.java:466)
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:404)
at org.eclipse.swt.widgets.Control.isVisible(Control.java:3175)
at org.eclipse.swt.widgets.ProgressBar.timerProc(ProgressBar.java:276)
at org.eclipse.swt.widgets.Display.windowTimerProc(Display.java:4378)
at org.eclipse.equinox.launcher.JNIBridge._takedown_splash(Native Method)
at org.eclipse.equinox.launcher.JNIBridge.takeDownSplash(JNIBridge.java:167)
at org.eclipse.equinox.launcher.Main.takeDownSplash(Main.java:2043)
at org.eclipse.equinox.launcher.Main$SplashHandler.run(Main.java:111)
Oodini's bug is a totally different use case. (In reply to comment #2) > Created attachment 203549 [details] > Frozen Eclipse stack dump Hello Sarah, Thank you for the provided information, it is really helpful, although I can't say I understand now where it should be fixed. It seems that issue is related to the SVN Kit implementation of the svn+ssh protocol (I assume it is the protocol you're using to connect with the SVN server, right?), but it doesn't seem I can find any issues in the SVN Kit code, that could lead to the deadlock as it was happened in your case. On the other hand I'm not the SVN Kit library author, so it's expectable for me to not have deep knowledge of its actual workflows. So, for now I've filled corresponding report in the SVN Kit tracker: http://issues.tmatesoft.com/issue/SVNKIT-131 Thank you Alexander, And yeah, we're using svn+ssh to connect. Fortunately this doesn't seem to happen to me too often, maybe once a month. My guess is it may have to do with a slow response from the server side, as our server sometimes hangs. The last time it happened, I seem to recall that I got tired of waiting after maybe 20 sec and put it in the background. However I think the first time, when I files the bug, I left it in the foreground for several minutes. It would be nice if it were possible to kill a plug-in, or at least have some kind of force-save option to write out your files and close down the IDE without corrupting your workspace. It's really annoying when you have unsaved work and you can't save it because some process is making your save wait in queue. Anyway, at least it's progress :-) I'll watch what happens with SVNKit. BTW it's funny how you can yell at the QA guys all the time for not attaching a proper stack trace and/or log file with a bug and then go do exactly the same thing when you're the frustrated consumer. Oh well :-) It seems the issue is solved in the SVN Kit 1.3.6 and now we have SVN Kit 1.3.6 support (see bug #363000). The changes will be included into the next "early access" build. |