Debugger on vacation?

Has anyone experience the debugger refusing to stop at breakpoints? Yesterday I was happily debugging away; today no breakpoints are honered in any location. No exceptions. Of course I did a bit of refactoring in between, and I'll revert back and checkit out. But it would be very strange for code refactorings to trigger this behavior.

Just wanted to see if anybody else could say "yes, that happened to me, you just need to..."

0
10 comments

Well, I reverted back to what I checked in last night and still no breakpoints. So as I expected, its nothing to do with the code.

Next I created a hello-world project, and of course the debugger is breaking correctly. So something in my project has killed the debugger. I guess I'll have to rebuild it from scratch to track it down. Strange.

0

I've isolated it down to a toy. In the file below I set breakpoints on the println statements.

- With the main method part uncommented the debugger does break
- With the junit3suite part uncommented the debugger does break
- With the funsuite part uncommented the debugger does not break

Now yesterday I was breaking in funsuite methods all day long. I haven't updated any jars, or anything. Very strange. I guess I'll have to give up funsuite for now.

--------

package com.si.mtconnect.agent


import org.scalatest.FunSuite
import org.scalatest.junit.JUnit3Suite

/*

object SmokeTests {

    def main(args: Array[String]): Unit = {
       println("smoke")
    }
}

*/
/*

class SmokeTest extends JUnit3Suite {
   def testSmoke {
      println("smoke")
      true
   }
}

*/
/**/

class SmokeTests extends FunSuite  {


   test("smoke") {
       println("smoke")
       true
    }
}

/**/
---------

0

Sigh. Its not as simple as I thought. Even with JUnit3Suite, most of my breakpoints to not trigger. It seems that I have hit some level of complexity that breaks the debugger. This is going to be painful.

0

Yes. You right. Debagger in many situations can't stop. It's our problem too (I mean we should fix it), but it's really not simple.
I can suggest you to try wrapping your code into some method or another class and method. And execute this method instead this code. After this operation it's possible that debbuger will stop. It's not handy workaround, but it's real and you can use it.

Best regards,
Alexander Podkhalyuzin.



0

Hi Barry.

Looks like a problem in debugging companion modules, containing of classes/objects. Do you have class and object with the same name which debugger ignores to stop in?

With best regards,
Ilya Sergey

0

No Ilya, in my current applicaton I don't (yet) have any companion objects. But I suppose that ScalaTest might. Right now all my debugging is via running a test method.The little sample I posted above is a literal test case for the problem that I actually executed and was able to see the behavior I described. (ie, Its not just a description of what I am seeing in the larger case.)

-barry

0

Alexander,

This seems to work well in Idea 14.

Please advise if indeed the "improved debugger" solves this issue.

Thanks
Nick

0

That's very old thread. I can't say exactly, when it was finally fixed.

Best regards,
Alexander Podkhalyuzin.

0

I guess I am asking if the problems you were seeing at the time of your post are supposed to be fixed now and we should expect the debugger to be functional.

Thanks

0

As I know, all situations when debugger can't stop were fixed (the last one was about value classes).

Best regards,
Alexander Podkhalyuzin.

0

Please sign in to leave a comment.