Menu
▾
▴
#648 Using debugger freezes Eclipse in some cases
Hello,
I'm using Eclipse together with Epic, which is a great tool to develop in Perl. However, I'm having some troubles with the debugger since some time. Here's the whole story.
When I launch a debug session on the debug view, it can have many side effects, from getting the CPU 100% to preventing eclipse to close correctly. But as I'm not a Java expert - only a Perl programmer, I have difficulties to understand what's going on under the hood. However, here are some of my findings about the causes and a little bit about the consequences.
1/ When I launch a debug session on a perl file, if I interrupt it with ctrl+f2 (or by clicking on the 'Terminate' button on the debug view), it seems that a java thread starts an infinite loop as the cpu goes to 100%.
After that, it's impossible to set a breakpoint by double clicking on the right margin (Or even by doing 'toggle breakpoint', it just won't appear).
As far as I could see with 'ps -eLf' it's the penultimate java thread that goes mad.
2/ Once a second debug is interrupted with ctrl+f2, cpu goes to 200% (I have a dual core)
Again, the penultimate thread goes mad (there are actually two threads at 100%).
When 1/ and 2/ are done, if I try to exit from Eclipse, the 'progress information' window stays there telling that 'the user operation is waiting for background work to complete' / 'saving workbench state'. And nothing appears. Only my CPU around 200%, but Java memory occupation does not change. I waited for a long, long time at this step to see if something was happening (like 2 hours).
If I do only 1/ (i.e, launching and aborting a debug session only once), I get java to go up 100% cpu, but I can exit correctly from eclipse and have my workbench state saved.
A strace on eclipse shows that one thread is blocking on futex(0x7f352aff69d0, FUTEX_WAIT, 27874, NULL)
By the way, 27874 seems to be a PID, as for this time, java had PID 27873,
PID 27874 cmdline is /usr/bin/java-Xms40m-Xmx384m-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins-Djava.library.path=/usr/lib/jni-XX:MaxPermSize=256m-jar/usr/lib/eclipse//plugins/org.eclipse.equinox.launcher_1.2.0.dist.jar-oslinux-wsgtk-archx86_64-showsplash-launcher/usr/lib/eclipse/eclipse-nameEclipse--launcher.library/usr/lib/eclipse//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.100.dist/eclipse_1408.so-startup/usr/lib/eclipse//plugins/org.eclipse.equinox.launcher_1.2.0.dist.jar--launcher.overrideVmargs-exitdata5b8013-vm/usr/bin/java-vmargs-Xms40m-Xmx384m-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=/usr/share/eclipse/dropins-Djava.library.path=/usr/lib/jni-XX:MaxPermSize=256m-jar/usr/lib/eclipse//plugins/org.eclipse.equinox.launcher_1.2.0.dist.jar
Funny because I can see PID 27874 on /proc, but not with ps auxfw ... !
Even funnier : doing cd /proc/27874 works, but if I ls /proc, 27874 dir does not appear...
I'm running Ubuntu 12.04.1 LTS on a x86_64 box, with the following software versions :
perl : perl5 (revision 5 version 14 subversion 2)
java : 6.26-2maverick1
eclipse : 3.7.2-1
Epic : 0.5.46
Everything is installed from Ubuntu packages.
leo@leostation:[/etc/../sources.list.d]$ dpkg -l '*sun-java*'
Souhait=inconnU/Installé/suppRimé/Purgé/H=à garder
| État=Non/Installé/fichier-Config/dépaqUeté/échec-conFig/H=semi-installé/W=attend-traitement-déclenchements
|/ Err?=(aucune)/besoin Réinstallation (État,Err: majuscule=mauvais)
||/ Nom Version Description
+++-============================-============================-========================================================================
un ia32-sun-java6-bin <aucun> (aucune description n'est disponible)
un ia32-sun-java6-plugin <aucun> (aucune description n'est disponible)
un sun-java5-jre <aucun> (aucune description n'est disponible)
ii sun-java6-bin 6.26-2maverick1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture dependent files)
un sun-java6-fonts <aucun> (aucune description n'est disponible)
un sun-java6-jdk <aucun> (aucune description n'est disponible)
ii sun-java6-jre 6.26-2maverick1 Sun Java(TM) Runtime Environment (JRE) 6 (architecture independent files
un sun-java6-plugin <aucun> (aucune description n'est disponible)
Im' using the Sun JRE :
$ ll /etc/alternatives/java
lrwxrwxrwx 1 root root 36 févr. 23 2011 /etc/alternatives/java -> /usr/lib/jvm/java-6-sun/jre/bin/java*
Note that I have exactly the same problems when using another JVM, such as openjdk.
Here is some extra info about processes 27873 and 27874 :
leo@leostation:[/proc/27874]$ cat status
Name: java
State: S (sleeping)
Tgid: 27873
Pid: 27874
PPid: 27860
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 4 20 24 40 46 111 119 122 123 126 1000 1001
VmPeak: 2307504 kB
VmSize: 2305444 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 304316 kB
VmRSS: 295364 kB
VmData: 1796072 kB
VmStk: 136 kB
VmExe: 36 kB
VmLib: 243028 kB
VmPTE: 1520 kB
VmSwap: 0 kB
Threads: 53
SigQ: 1/31442
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000004
SigIgn: 0000000000001000
SigCgt: 1000000181004ccf
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 31425
nonvoluntary_ctxt_switches: 47428
leo@leostation:[/proc/27873]$ cat status
Name: java
State: S (sleeping)
Tgid: 27873
Pid: 27873
PPid: 27860
TracerPid: 28413
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 4 20 24 40 46 111 119 122 123 126 1000 1001
VmPeak: 2307504 kB
VmSize: 2305444 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 304316 kB
VmRSS: 280848 kB
VmData: 1796072 kB
VmStk: 136 kB
VmExe: 36 kB
VmLib: 243028 kB
VmPTE: 1508 kB
VmSwap: 0 kB
Threads: 53
SigQ: 1/31442
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 1000000181004ccf
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: ffffffffffffffff
Cpus_allowed: 3
Cpus_allowed_list: 0-1
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 16
nonvoluntary_ctxt_switches: 2
Is there any extra testing that I can perform to help debugging ?
Thank you in advance for your help.
It would be interesting to know whether these problems also occur with EPIC 0.6.x (testing). Please upgrade and report back. The reason I'm asking is that there are significant differences between stable and testing in the debugging department (testing is generally newer and better), so it doesn't seem worthwhile to troubleshoot if the bug is somehow related to the old code.
Another suggestion would be to use a 32 bit JVM (and Eclipse) to see if that fixes anything.
You can't really gain much insight into what's going in the JVM using OS-level tools only. The correct approach for gathering more information would be to observe the Eclipse instance under debugger, see "Hacking EPIC in 15 minutes" at http://www.epic-ide.org/devguide.php
Hello,
I pugraded to version 0.6.x and the problem disappeared. Also, I first deleted my ~/.eclipse and workspace directories to be sure that I started with a clean install.
At first, I did not want to use the testing version, as I prefer having a very stable environment. So I believe the bug can be closed...
I just have some extra comments that may help people having strange problems with Eclipse / Epic.
I work on a project stored on a Svn repository, so I also use Subclipse together with Epic. When I imported my project inside eclipse, some weird things happened from time to time; like, it was impossible to create a new debug configuration - I got an error like "unable to load class org.epic.debug.Launch".
What happened is that my Svn repository had silently versionned the .includepath, .project and .settings files and dirs that are created by Eclipse inside every project directory. Those files were created on an older Eclipse / Epic version and seemed to create some mess. Once I deleted them, everything got back to normal.
Let's say that Eclipse is a great tool, but has some weird behaviour like putting files in every single possible place.
Thank you four your help anyway !
Léo.