Bug in scala ide debugger - not hitting break points

105 views
Skip to first unread message

Duckpodger

unread,
Mar 30, 2015, 12:38:36 PM3/30/15
to scala-i...@googlegroups.com

The problem

Some Scala code I'm working on calls out to a Java library which runs tasks in an executor service. I am trying to debug some code in the runnable that gets submitted (written in Java). I have a single breakpoint within the runnable.

My problem is that when I debug, my breakpoint never seems to be hit and the code within the runnable never executes.

Below you will find an extremely simplified version of the code in question. In this sample, the line on which I set a breakpoint is line 14. If you try and reproduce my issue, you will also notice that he process never terminates (A clue).

Summary of observable behaviour:

  • No break points
    • all tasks executed
    • process runs to completion

  • Break points on line 14 AND on line 10 (my current workaround)
    • all tasks executed
    •  both break points are hit for both tasks
    • process runs to completion

  • Break point ONLY on line 14 (problem case)
    • Tasks are submitted
    • Neither task runs
    • Neither breakpoint hit
    • Process doesn't complete

The explanation

When I do a thread dump on the process in the problem case, I can see two threads:

"pool-1-thread-2" prio=6 tid=0x0000000013157800 nid=0x302c at breakpoint[0x00000000156df000]

   java.lang.Thread.State: RUNNABLE

"pool-1-thread-1" prio=6 tid=0x0000000013155800 nid=0xa10 at breakpoint[0x0000000014b6e000]

   java.lang.Thread.State: RUNNABLE

As you can see, Eclipse/Scala IDE has installed the breakpoints and they have triggered. The problem is that the IDE hasn't noticed this and doesn't show the threads suspended.

I suspect that the problem is that two threads are both activating a breakpoint on the same line of the same file at the same time (for some definition of same time). I think that this is confusing the Scala IDE debugger.

The boring bits

Eclipse: 3.8.2

Scala IDE: a slightly customised fork of 4.0

The example code:

Gog.scala – The main to tell Scala IDE to debug:

package d

object Gog extends App{
  val magog
= new Magog()
  magog
.submitTasks()
  magog
.waitExit()
}


Magog.java – The code that uses the executor service and in which breakpoints are to be set

package d;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class Magog {
 
private final ExecutorService exec = Executors.newFixedThreadPool(2);

 
public void submitTask(){
   
System.out.println("Going to submit task"); //line 10
   
exec.submit(new Runnable(){
     
@Override
     
public void run() {
       
System.out.println("Running task"); //line 14
     
}
   
});
 
}

 
public void submitTasks(){
    submitTask
();
    submitTask
();
 
}

 
public void waitExit() throws InterruptedException{
   
exec.shutdown();
   
System.out.println("Shutdown complete");
 
}
}


iulian dragos

unread,
Mar 31, 2015, 6:20:38 PM3/31/15
to scala-i...@googlegroups.com
On Mon, Mar 30, 2015 at 5:53 PM, Duckpodger <matthe...@gmail.com> wrote:

The problem

Some Scala code I'm working on calls out to a Java library which runs tasks in an executor service. I am trying to debug some code in the runnable that gets submitted (written in Java). I have a single breakpoint within the runnable.

My problem is that when I debug, my breakpoint never seems to be hit and the code within the runnable never executes.

Below you will find an extremely simplified version of the code in question. In this sample, the line on which I set a breakpoint is line 14. If you try and reproduce my issue, you will also notice that he process never terminates (A clue).

Summary of observable behaviour:

  • No break points
    • all tasks executed
    • process runs to completion

  • Break points on line 14 AND on line 10 (my current workaround)
This is a very good clue. I can reproduce it. As another workaround you can use the Java launcher (in your Debug configuration, choose the non-Scala launcher).

Background info: the JVM debug interface requires a class to be loaded in order to set a breakpoint. So the debugger intercepts class load events in order to install "delayed" breakpoints (for line numbers that fall into classes that have not yet been loaded). We seem to miss doing that for anonymous Java classes. At least, this would be my starting point for investigation :)

iulian

 

--
You received this message because you are subscribed to the Google Groups "Scala IDE User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-ide-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scala-ide-user/3276d026-7223-4a80-aac1-60f5c30bf40a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
« Je déteste la montagne, ça cache le paysage »
Alphonse Allais

iulian dragos

unread,
Mar 31, 2015, 6:23:57 PM3/31/15
to scala-i...@googlegroups.com

Duckpodger

unread,
Apr 13, 2015, 11:26:34 AM4/13/15
to scala-i...@googlegroups.com
Thanks for filing that. I hadn't twigged that anonymous classes might also be a factor.

When adding IDE support for a new language using all the language features at the same time always produces the most pointy corners :0)
Reply all
Reply to author
Forward
0 new messages