Having difficulty with Subversion

I am having failed commits, but browsing repository from within Rubymine shows some recent commit messages..

Right now, I have the 'Commit Changes' window open, but it does not have minimize, maximize, close at the top right. Also, action buttons are little with no writing. It will not close. Even when I right click window at the top and select 'Close' from the dropdown list.

Cannot do anything except kill from a shell window.

If I kill -9 <process ending in rdebug-ide> window is still there.

If I kill -TERM <process starting with /bin/sh and ending in Rubymine.sh> window is still there.

If I kill -9 <process starting with /bin/sh and ending in Rubymine.sh> window is still there, but 'ps ax | grep ruby' shows no ruby/rubymine processes.

Rubymine window and 'Commit Changes' window is still there...

I can move Rubymine window, I can move 'Commit Changes' window..

I am running Fedora 15 with Gnome 3.0.1 and Rubymine 3.2.2

ps ax |  grep idea  shows one process

kill -TERM <idea process> Does actually kill off the Rubymine and 'Commit Changes' window

Any suggestions on how to get Subversion to work again?

Comment actions Permalink


Please take a threaddump when RubyMine hangs, for just invoke in console "jstack <rubymine_pid>" command

Comment actions Permalink

Not sure that this is what you need:

[user1@hoho6 db]$ date
Tue Aug 23 11:27:47 CDT 2011
[user1@hoho6 db]$ ps ax | grep ruby
8165 ?        S      0:00 /bin/sh /home/user1/Downloads/RubyMine-3.2.3/bin/rubymine.sh
8386 pts/1    S+     0:00 grep --color=auto ruby

[user1@hoho6 db]$ jstack -F 8165
Attaching to process ID 8165, please wait...
sun.jvm.hotspot.debugger.NoSuchSymbolException: Could not find symbol "gHotSpotVMTypes" in any of the known library names (libjvm.so, libjvm_g.so, gamma_g)
    at sun.jvm.hotspot.HotSpotTypeDataBase.lookupInProcess(HotSpotTypeDataBase.java:389)
    at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:104)
    at sun.jvm.hotspot.HotSpotTypeDataBase.<init>(HotSpotTypeDataBase.java:85)
    at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:568)
    at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:494)
    at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:332)
    at sun.jvm.hotspot.tools.Tool.start(Tool.java:163)
    at sun.jvm.hotspot.tools.JStack.main(JStack.java:86)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:616)
    at sun.tools.jstack.JStack.runJStackTool(JStack.java:136)
    at sun.tools.jstack.JStack.main(JStack.java:102)
Debugger attached successfully.
jstack requires a java VM process/core!
[user1@hoho6 db]$

Comment actions Permalink

Since my principal problem is with Subversion, I tried a command line commit:

[user1@hoho6 DummyRails]$ svn commit -m "command line commit"
Sending        DummyRails/.idea/DummyRails.iml
Sending        DummyRails/app/controllers/transaction_paths_controller.rb
svn: Commit failed (details follow):
svn: File '.idea/dictionaries/user1.xml' is out of date
svn: File not found: transaction '18-11', path '/DummyRails/.idea/dictionaries/user1.xml'
[user1@hoho6 DummyRails]$

What hack will get me back on the right track?

Comment actions Permalink

Could you caputrue a threaddump without "-F" flag? Unfortunatelly you threaddump doesn't show any info about RubyMine related threads

Comment actions Permalink

OK, my two problems seem to be solved.

The Subversion difficulty was solved by moving the working directory aside, creating a new working copy by exporting from SVNrepo, then copy files from the moved original working directory over the newly exported files. The copy overwrites the exported files, but does not overwrite /.svn/ files. rsync was helpful here. Also the StackOverflow list was helpful.

The cause of the Subversion difficulty is cloudy. Perhaps the password to the SVNrepo held within the RubyMine application got clobbered during a version update. By the way, I have been running RM version 3.2.3 all the time. I was in error when I originally said 3.2.2

All of the Subversion file manipulation was done from a shell command line. I had to re-insert the SVNrepo password to get RM to work with Subversion.


The RM window that would not go away problem hasn't come back. It happened when a window without 'minimize,fullscreen,close' buttons got distorted so that the buttons lower down on the window were not functional.

I noticed that when you do Run->Edit Configurations->Help, the Help window does not have 'minimize,fullscreen,close' buttons. However, a right-click on the top of the Help window pops up a menu which includes 'close'.. This works.

Thanks much to all. I'm working again.

Comment actions Permalink

The cause of the Subversion difficulty is cloudy. Perhaps the password to the SVNrepo held within the RubyMine application got clobbered during a version update.

Yes, most likely, that is why threadump captured using jstack cmdline utitlity could be helpful.

Comment actions Permalink

I tried jstack, but the result was blank. I read a bit of the jstack doc and tried the -F flag. I did get some output as provided earlier in this discussion.

Comment actions Permalink

When I need to kill rubymine I do a kill on the java process, not the shell script. In my case, I am not running other java applications so I simply do a

killall -9 java

If you don't wan't to kill all java processes, you can look in ps ax for the specific process id and do kill -9 <process id>

The process looks like this in my case:

ps ax | grep java
3009 ?        Sl     2:57 /usr/lib/jvm/java-6-sun- -Xms32m -Xmx512m -XX:MaxPermSize=150m -ea -Xbootclasspath/a:../lib/boot.jar -Didea.platform.prefix=Ruby -Didea.no.jre.check=true -Djb.restart.code=88 com.intellij.idea.Main

in this case, kill -9 3009 would work.


Comment actions Permalink

As mentioned in my original post, I did as you suggest.

However, at that moment, it seemed like the phantom window was owned by a process with 'idea' in the name.

As, I mentioned, I could move this phantom window around, but clicking on it did not do anything. Perhaps it was just a frame of pixels owned by the 'idea' process.

When I killed the 'idea' process, then the frame of pixels disappeared.


Fortunately, I haven't been able to duplicate the effect.

Comment actions Permalink

Sorry about not reading your post thoroughly enough :)


Please sign in to leave a comment.