I recently installed the JRebel plugin for NetBeans and have noticed the following problem when debugging within the IDE:
If I set a breakpoint in a class and change the code afterwards, then my debugger doesn't always hit the breakpoint. I found a workaround: resetting the breakpoint (or reattaching the debugger to project) after reloading the class.
But this solution is not perfect because class is reloaded when app needs it for the first time(debugger doesn't work yet) so I have to make some action which I want to debug two times which can cause so many problems.
Another thing is what I can't explain at all.. even when I hit the breakpoint with success, I can't hit another one in another class.
Maybe someone has figured this issue out - ? Is there a way to reload changed classes on save?
NetBeans 7.2.1 with JRebel plugin, Glassfish 3.1.2
This is a known issue. The solution exists but not released yet.
Also, please check Options->Java->Java Debugger. Is the "Apply code changes after save" checkbox enabled? If not, could you enable it and try in this configuration - will it make any difference?
Related
I was debugging a GoLang program. I set break points and run the debugger. But the break points only works the first time I run the debugger and failed in the second, the third, and all following debugging whatever I do. I cancelled them and reset them, I close the debugging window and open a new one, I change the settings in the "Breakpoints" tool window. All these didn't work at all.
What's the problem?
Update, this has been fixed in the latest release of the plugin, please check it out
This is a well known problem and it lies in delve not the plugin itself. Please see this this issue for further reference.
I have an MVC5/EF app that I can't seem to debug at all. I have a console app also in the project that I can debug just fine, but when I set a breakpoint in a controller it won't debug. I've googled this but can't find anything that can help.
MVC 5 and EF most certainly works in debug. It even debugs jquery. So you must have something not right.
I would check all the projects build debug settings. Make sure build mode is debug.
Add some breakpoints early on to see if they are getting called.
Difficult to pin point the exact problem considering we can’t see your project’s solution.
But for the record, you mention that you have both an ASP.NET MVC application AND a Console application living within the same project.
Since you’re also saying that you can debug the console application, could it be that the Console application is the one that is Set as StartUp project and NOT the MVC application?
If that’s not the case, can you tell us which of your projects is Set as StartUp Project?
I wanted to know is there any way in IDEA putting debuggers' breakpoint to previous row where debugger has just passed and re-run that scenario again. Because when debugging a loop, it's a bit tedious going to a UI doing desired action for handling that case again. I think such feature is available in Visual Studio. I've tried to google it but unfortunately I could not found anything about it.
I've submitted an issue on IDEA's bug tracker but its status changed to won't fix with this comment:
This functionality is not supported by the JVM. It's not possible to
implement it in IntelliJ IDEA without JVM support.
http://youtrack.jetbrains.com/issue/IDEA-84257?projectKey=IDEA
I've been using Scala 2.8RC1 and Scala Eclipse plugin for 2.8 RC1 happily for a few days. However, last night after adding a couple jar files to my environment (apache http client jars) the debugger just stopped stopping at breakpoints in scala code.
Java code stops fine at breakpoints. I tried creating a new mimimal scala app breakpoints don't stop. I've tried switching to sun-jre-1.6.0.20 from the openjdk-1.6.18 I had been using. I've switched to the scala 2.8 nightly and also eclipse plugin for scala nightly builds. No luck.
I would greatly appreciate ideas for fixes. Rather frustrating as the initial experience with 2.8 was really great.
https://www.assembla.com/spaces/scala-ide/tickets/2731-breakpoints-against-objects-in-default-package-are-not-honoured
Says that scala eclipse plugin doesn't stop at breakpoints if you're class is in the default package (no package)
Adding a package and moving my class to it - make the debugger start working again.
It's possible that you've discovered a bug in the Scala tooling for Eclipse. The best place to take the issue is the scala-ide-user list here,
http://groups.google.com/group/scala-ide-user
If you're already sure that you've found a bug you can find instructions for opening a ticket here,
http://scala-ide.assembla.com/wiki/show/scala-ide/Bug_Reporting
I've just encountered this problem. Code is not in default package. I'm getting a warning about missing line numbers, but apparently that bug has been fixed and I can ignore the warning, per https://scala-ide-portfolio.assembla.com/spaces/scala-ide/tickets/1000155-its-impossible-to-add-line-numbers-debug-info-to-compiled-project#/activity/ticket:
It did seem to stop at breakpoints in the main file, though.
I'm using watermark extenders on textboxes and an exception is being thrown from the AJAX Control Toolkit .dll. It's strange because this just started happening.
I tried debugging from the Ajax solution and Ajax examples (but with my code), but no dice.
Is there a way to step into the Ajax .dll from my solution to see where this is happening?
Couldn't you just get the source for the Ajax Control Toolkit and include it as a project in your solution and then reference it? You'd then be able to step into the code and if you really needed to, you can just put the precompiled one out when you deploy out.
The source code for the AJAX Control Toolkit is available from:
http://www.codeplex.com/AjaxControlToolkit/Release/ProjectReleases.aspx?ReleaseId=16488
Just download and start debugging.
You don't need to include the AjaxControlToolkit project. Just open the file you need (in the VS instance where your code that currently breaks is), and set a breakpoint where appropriate.
Maybe a black box approach is more appropriate here. You said that this error just started - what has changed in your environment to start this? You may be headed down a rabbit hole by stepping through the code. Can you deploy to a clean environment and not get the error? Or, does it work in the dev but not the test environment?