I'm trying to debug my Client-Server UDP program to see what it is doing but when I get to the .receive() method (in either the client or the server code) the break point disappears and the step-into/step-over buttons turn gray. What I see next to the .receive() method call is a little white arrow that says "debug call stack" when I hover over it. What exactly is happening?
Has it something to do with the fact that it's a blocking call? If so how do I get past beyond this point?
Your call is blocked on that line, waiting for a read.
You can place another breakpoint right after that specific line. It will break after the receive() is done.
The block is probably native, so you can't really debug it. However, if you never get to the second breakpoint, you know that there is problem ;-)
Related
I have a global variable
static int debugNumber;
and a breakpoint with a condition
debugNumber > 1
with Suspend thread, Conditional and Suspend when 'true' checked. Currently, if I pause the execution of the program and hover over the declaration the value displayed is 2. Still, this breakpoint doesn't break.
As far as I can see on Google and here at SE debugNumber > 1 should be fine. What am I doing wrong?
Just so we're clear: That line means: If code execution gets to this line (the line with the breakpoint), then do what breakpoints usually do: Freeze the thread (or if you've configured things to be that way, and pause all other threads, which is not the default). However, a conditional breakpoint means: Before breaking as usual, check the condition. If the condition is false, then don't do anything.
A conditional breakpoint is going to break as often, or less often, than a normal breakpoint, never more often.
It sounds like what you want is to 'breakpoint' every line in the codebase that sets the debugNumber variable, if the value it is being set to is 2 or higher. If that's what you want, make a 'watch' on debugNumber and configure the watch to break execution.
If that's not what you wanted, then, well, you made no mistakes in what you describes, so then it's one of a billion things that could be wrong:
The line with your breakpoint was never hit.
The debugNumber was 1 or less when it hit your breakpoint.
You used 'run' to start your application and not 'debug' (there's pretty much no reason to ever 'run' anything, always pick 'debug')
The global 'disable all breakpoints' toggle within eclipse has been toggled off. It's (unless you changed things) on the toolbar: a larger 'breakpoint dot' (blueish circle) with a big slash through it. It's a toggle button. Is it pressed in?
Eclipse debugger has desynced. It will throw you a dialog if this happens, but one of the options in this dialog is 'ignore now and in the future' (It's a more succint text than that, but that's the gist of it). If you ever pressed that, it can desync. The debug view will tell you. This can happen if you change compiled code as eclipse runs, or change signatures in your source files and save the source file in the middle of a run.
Many many more things
I've been making a simple server that receives messages from multiple clients, then returns "hello" to the client. However, when I debug the program I run into issues, where some lines of code seem to freeze the debugger. This happens when I step through the program while debugging, and certain lines will cause me not to be able to continue stepping through the program. The "Continue", "Step Over", "Step Into", and "Step Out" can be clicked, but they don't advance the program.
Here is just one of the problem code blocks:
if(key.isReadable()){
String message = readFromChannel(key);
System.out.println(message); // Debugger always freezes here
sendToChannel(key, "hello");
}
I have never seen System.out.println() block, and I am thoroughly confused as to why this line of code seems to freeze the program.
Any help appreciated, as this is incredibly annoying.
I am using VS Code on MacOS Catalina, v1.14.1
The problem seemed to be caused by the expressions in the Watch tab. It works fine after I removed all the expressions from under the tab.
I am writing an application in Java to make calls and view when people are in calls, their phone is ringing or are idle, using the library Jain-Sip and at the moment am trying to correctly implement presence with SUBSCRIBE and NOTIFY messages. I am able to get presence data to be received, but after a while the presence data stops being displayed by my program.
I believe this is because the overridden method "processRequest" is not being called. This is the earliest point in the program where NOTIFY messages are being handled and not even the print statements are being output.
The bizarre thing about this is that the notify messages are being sent when I make calls, and the presence data is there. I know this because I have done Wireshark traces when running the program.
Note: No exceptions are occurring during execution of the program, to cause erroneous behaviour.
If anybody has any insight into why this is happening, I would be very grateful.
Thanks a lot,
Adam
Make sure you add your listener class correctly. The only other possible cause would be if the NOTIFY is unsolicited, which should not be the case but it happens. Try to enable this flag gov.nist.javax.sip.DELIVER_UNSOLICITED_NOTIFY. See more about it here https://jsip.ci.cloudbees.com/job/jsip/javadoc/gov/nist/javax/sip/SipStackImpl.html
Otherwise you will need to attach DEBUG logs to figure it out, could be malformed request or something of the sort.
Netbeans has a tabbed window in the Output section called "Debugger Console". Is it possible to write a message to this window using Java? If so, how?
The messages you see in the debugger console are either
informations given by the debugger itself (breakpoint added, for example)
custom messages associated with a breakpoint
When you add a breakpoint to a line of code, the default behavior of the breakpoint is to suspend the thread that executed the line of code, and to print the text "Breakpoint hit at line {lineNumber} in class {className} by thread {threadName}.".
You can configure a breakpoint to print a custom text. This text will be output in the debugger console when it reaches the breakpoint. To do so, right click on a breakpoint, open the propoerties window, and enter your text in the field Print text.
A useful trick is to configure a breakpoint so that it does not block (suspend : no thread), and to enter a text. The effect is the same than adding println lines in your code, but the benefit is that you don't have to recompile the code, and it's easier to activate/deactivate these debugger logs (and it obviously does not stay on production code).
Note that, in the text of the breakpoint, you can use one of the special values {lineNumber}, {methodName}, {className} or {threadName}, and you can also evaluate some code with the syntax {=xxx}. Just replace xxx with a variable name, or a method call, or whatever.
OK for me it's in Output > Glassfish server 3+ Console
I wrote a simply System.out.println in my program and when the debugger arrive on this instructions the console diplay the result of my simply writing.
For others situation I don't know
I'm working on a multithreaded program in Java that uses a shared array to pass data between threads. It's being developed in Netbeans 6.7.1.
One of the threads only seems to work when a breakpoint is placed in it, it doesnt matter where it is.
Running in debug mode with no breakpoints acts the same as running in release - the expected output never arrives.
I can't tell where the problem occurs, as the moment a breakpoint is added and I press continue, it works as expected.
How can I narrow down where/why this problem occurs?
Example code:
result = utils.isBufferFull(AudioDuplex.voiceArray);
if(result == true) {
System.out.println("Taking copy");
voiceArray = AudioDuplex.voiceArray;//.clone();
utils.clearBuffer(AudioDuplex.voiceArray);
}
If a breakpoint is placed on line 2, it is never hit.
A breakpoint on line 3 will be hit, and the expected output will arrive.
It's impossible to tell exactly what's wrong without a lengthier code sample, but in my experience, this kind of behavior is typical of unrecognized producer-consumer problems (see http://en.wikipedia.org/wiki/Producer-consumer_problem).
Basically, what's probably happening is that your producer thread does not have the data available when the consumer thread is requesting it. The basic solution is to keep a semaphore (there is a Sempahore class in java afaik). The producer would post when it has the data, the consumer would wait until the producer posts.
What you're seeing with the break point is you stopping the consumer thread for a long enough period that the producer can offer something. When you don't break, the consumer runs normally, and exits before the producer has anything.
Write the values of the involved variables to a log file, the console or add them to an array and print them as soon as you get the error.
Your problem is probably a runtime issue (a second thread updates an involved variable). Since breakpoints only stop the active thread, the second thread gets its work done so the code works.