21

Does IntelliJ IDEA provide thread-debugging? That is - Netbeans allows you to debug multiple threads, and halting at those breakpoints (automatically). However all I seem to be getting in IntelliJ is "thread dumping", which seems to be an analysis that is manual, and a snapshot taken when I clicked 'Thread Dump'.

Is there something I'm missing? I have google'd and not found sufficient information to assist.

RNJ
  • 15,272
  • 18
  • 86
  • 131
Dane Balia
  • 5,271
  • 5
  • 32
  • 57
  • it is unclear what your problem is. you have a breakpoint in a thread but IntelliJ does not stop there? – Denis Tulskiy Sep 25 '12 at 10:44
  • Yip - it doesn't stop at all. It appears to complicated to set this individually. In NetBeans a "breakpoint" is just that - a breakpoint. Switching back to "NetBeans". Thanks for the help guys. – Dane Balia Sep 25 '12 at 10:45
  • 1
    @DaneBalia You can make each breakpoint in IntelliJ *just that - a breakpoint*. Make sure that the `Thread` policy is the default. – maba Sep 25 '12 at 10:53
  • Hmm....ok, will try it. If you guys are certain then the problem is with me. Will check my CODE, I must be doing something DUMB. – Dane Balia Sep 25 '12 at 10:53

5 Answers5

28

I think you can. I have suspended threads via breakpoints by setting the suspend policy. This will suspend the thread that is executing this piece of code. If you have multiple thread then I would think they would carry on.

To quote the suspend policy

  • Item Description
  • All : When the breakpoint is hit, all threads are suspended
  • Thread : When the breakpoint is hit, the thread where the breakpoint is hit is suspended.
  • None: No thread is suspended.
RNJ
  • 15,272
  • 18
  • 86
  • 131
  • 2
    Thanks - I did alter the "suspend policy" and even made the default to "Thread" - but still no suspension. I then spawned just'one' thread, (commented out the second) - and still there is no breakpoint. When I do a thread dump, I do see an error - but I have a breakpoint before that line. This is weird. You have any ideas? – Dane Balia Sep 25 '12 at 10:41
  • 1
    How are you building/running? At times when I deploy my code can be out of date to what is deployed. If that happens then my breakpoints go really funny... – RNJ Sep 25 '12 at 10:54
  • You right - it's working now. Did a proper build and all is well. Thanks guys. also made all breakpoints default to 'Thread' – Dane Balia Sep 25 '12 at 10:58
  • 1
    The real reason for the problem was that I had created a whole bunch of breakpoints prior to setting the suspend policy, and even though I set "default" to Thread, the old breakpoints were set to "All". I had to manually reset them to the default. That WORKED! So that was IT! – Dane Balia Sep 25 '12 at 11:18
8

You have a nice Threads view available.

Press the little gearwheel and you will see all active threads.

enter image description here

And on each breakpoint you can set the Suspend Policy. You can either make the Thread alternative the default for all breakpoints or you can set them individually on each breakpoint.

enter image description here

maba
  • 47,113
  • 10
  • 108
  • 118
3

For me the problem with not accessing thread still occcurs. I set up brakepoints to all. And put brakepoints inside calling methods. What I noticed is that the method in new thread is beeing accessed when i call run() but not start(). Just wondering why, AFAIK the start() method should call run(). Nevertheless, the output from thread occurs even I call .start(), but never access it.

Jacob
  • 14,949
  • 19
  • 51
  • 74
  • 1
    if you call run() the method runs synchronously, and when you call start the method run, runs asynchronously , when the method is run async the thread doesnt stop at the breakpoint for some reason – Lena Bru Jul 26 '14 at 17:16
0

For me the issue was that there seems to be a race condition with resuming threads after breakpoints and evaluating breakpoints in IntelliJ.

My short-term work around was to not set Breakpoints right before I spawn a thread. If I don't do this the first few Breakpoints in the run() or call() are missed.

kervin
  • 11,672
  • 5
  • 42
  • 59
0

I think the problem you have is that the child threads are being closed sooner than you expected because the main thread(the test itself) reaches to the end.

Remember that when you do a Thread.start() an asynchronous call starts, then if you are running your tests using Junit the execution will continue after this call until the end of the test, and as soon as it reaches to the end, it shutdowns the threads you started inside it.

Therefore, if you have something like:

01. import org.junit.Assert;
02. import org.junit.Test;
03. public class ThreadTest {
04.     static boolean didIGetIt = false;
05.     @Test
06.     public void testThread() {
07.         Thread myThread = new Thread(new Runnable() {
08.             @Override
09.             public void run() {
10.                 System.out.println("I am an asynchronous task");
11.                 System.out.println("and JUnit won't wait for me to finish my job!");
12.                 didIGetIt = true;
13.             }
14.         });
15.         myThread.start();
16.         Assert.assertTrue(didIGetIt);
17.     }
18. }

It will execute the Assert before the code inside the run() leading to a fail test.

But if you add a simple sleep you could stop the main thread and debug and do what you need before the main thread stops.

01. import org.junit.Assert;
02. import org.junit.Test;
03. public class ThreadTest {
04.     static boolean didIGetIt = false;
05.     @Test
06.     public void testThread() throws InterruptedException {
07.         Thread myThread = new Thread(new Runnable() {
08.             @Override
09.             public void run() {
10.                 System.out.println("I am an asynchronous task");
11.                 System.out.println("and JUnit won't wait for me to finish my job!");
12.                 didIGetIt = true;
13.             }
14.         });
15.         myThread.start();
16.         System.out.println("Let's wait for child threads to finish");
17.         Thread.sleep(5000);
18.         Assert.assertTrue(didIGetIt);
19.     }
20. }

Surely there are better ways to do it, but the Thread.sleep may be what you are looking for.

Hope it may help somebody!

Marco Vargas
  • 1,232
  • 13
  • 31