This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
While debugging a module suite project "step into" does not reliably work.
Can you provide more details, please? How does it fail, does it behave like Step Over or does not it stop at all? What about Step Into Next Method action (Shift + F7), is it reliable when used instead of Step Into in the problematic cases?
Unfortunately I haven't found a way to reproduce the problem. When I tried to step into a method nothing happened (the current line was still highlighted with the green arrow). No exception has been reported. As a workaround I set a breakpoint in the method and hit Continue (F5). This worked.
I have not managed to reproduce it. There have not been reported any other similar issues, it seems it can occur only by some specific circumstances. Issue 168707 describes problems with Step Into when stepping trough unavailable source files. In such case, it can behave like Step over. However, this issue sounds like a different problem. A test case for the reproduction would be very helpful.
I am now debugging a NetBeans module project. I have one line breakpoint and one method breakpoint (stop on all methods). While I experience no lockups (bug 168139), Step Over and Step Into work strangely. In the beginning of the debugging session, everything seemed to be working fine. After several minutes, Step Over started to behave like Step Into time by time. Now, after some more time, even Step Into started to behave the other way, i.e. like Step Over, randomly. As a result, I never know whether F7/F8 will step over or into - the debugger seems to have its own soul. -- System Info (both the debugger and debuggee): NetBeans IDE 6.8 Dev (Build 090724) (#a893bb60c860) JDK 6u14, 64-bit, server VM Linux (Debian Lenny), 64-bit, Intel CPU
Marian, you've removed INCOMPLETE keyword, but did not add anything that would make this issue complete. I understand that this is a random issue, but any attempts to reproduce this failed for me so far. Hopefully it could help if you describe which part of NetBeans did you debug, where did you step from and where debugger did step into instead of step over and vice versa. Also, do you encounter such a behavior when both NetBeans are run on JDK 6u13 ?
I described what "does not work reliably" means - that's what I added. The next time it happens, I will try to add more specific information about what I am debugging and how. I have not tried to debug using JDK 6u13. Debugger stepping worked well during the last two debugging sessions. I will add more information the next time the debugger becomes crippled.
For I and my colleague step over doesn't seem to work _at all_. I've tried upgrading to 6.7.1. without effect, so it's not a freak bad installation. What happens seems to be more like a step out than either a step into or step over, but it doesn't step out just one level. We're running in XP SP2. Java 1.6_02. I can't see why this bug is so solid for us without being universal. It's a fairly complicated network of projects, but nothing that specialised. Will try updating JDK, maybe this is a Java version thing.
Nope, just the same on 1.6.0_16
I am sorry, but this issue is without requested information for long time - INVALID. We can't do anything in this case. Reporter or anyone else still experiencing this issue, please add requested information (steps to reproduce, suspicious logs, etc.) and reopen issue. Thanks in advance.
Created attachment 88430 [details] Messages log for very simple debugging step failure
Created attachment 88431 [details] Trivial program tested on
OK, what I find hard to understand is why everyone isn't getting these debugger problems. So I tried a minimal test program and cleared out the usual clutter of open projects on my Netbeans to eliminate the possibility that it's shear overload. I restarted Netbeans to ensure minimum clutter and a clean log. I simply placed the cursor on the first line of main and hit F4. That worked (though the first time I tried spend a ridiculous amount of time scanning class path). Then I hit F8, and the program simply ran to completion without going back to the debugger at all. There's some fairly extraordinary stuff in the log. The platform settings all look right, yet there's all this stuff about changing source level to 1.3. But the most relevant entries look like the IncompatibleThreadStateException exceptions recorded at the end of the log.
Created attachment 88433 [details] Netbeans configuration file for simple debugging case
I've having spotted the ImcompatibleThreadStateException in the log our problem might be related to http://www.netbeans.org/issues/show_bug.cgi?id=156408 Don't know if the previous posters on the thread have exactly the same problem. I tried changing the debug option to "suspend all threads", but that has no effect. This bug is really degrades the usefulness of the debugger for us. With this and the extreme UI sluggishness we suffer much of the time we're starting to think about Eclipse, to be honest.
closing incomplete issues
I'm having what appears to be exactly the same issue running IDE 7.3 on OSX 10.8.3 running java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) 64-Bit Server VM (build 23.7-b01, mixed mode) It's perfectly reproducible for me, but I'm not exactly having a minimal environment :-)
(In reply to Marian Mirilovic from comment #15) > closing incomplete issues Valuable suggestion - Apropos , if people is searching for a service to merge two PDF files , my business partner used a service here http://www.altomerge.com/.