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.
Related
I've done some research to know if there is an equivalent to PHP die in java
Sometimes I'm doing small tests and I really want to stop my code at specific line , and return doesnt stop the code like "die" in php
Is there a die quivalent in java?
Use System.exit(0); to exit the java code.
Keep a note this will stop the JVM instance which is currently running.
If you want to come out of a method use return or throw exception to showcase error condition.
try:
System.out.println(message);
System.exit(0);
Disclaimer: I'm not that familiar with Java, I have a basic working knowledge of it, but haven't done a huge amount of work with it.
I suppose you could just throw() an exception and not catch it, that should halt execution. Of course if you have an exception handler for exceptions that aren't caught locally you might have problems.
Most IDEs let you set breakpoints where execution will stop and you'll be able to examine the state of variables, look at the call stack and so on. Both Eclipse and Netbeans support this. It might be a better option.
EDIT: There is also System.exit() which will halt execution. I still think breakpoints are a better option though.
<% if(true)return; %> ok
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 ;-)
I am running Ubuntu 10.10 using Java 6 and can not get FreeTTS to output any audio. I have tried it now on 3 different computers and even asked a buddy of mine to try it on his Ubuntu PC and he had the same problem. There is absolutly no errors that are displayed, after getting the MBROLA i no longer even get the warning about No MBROLA voices detected. blah blah blah..
Using the same computer I ran a virtual box and started Windows XP, i was actually able to get audio when running the HelloWorld.jar and TTSHelloWorld.jar however the freetts.jar is still silent when I try to input my own text.
Command I use.
java -jar lib/freetts.jar -text Hello
When I hit enter it starts up and used to give me the missing MBROLA warning message but now it just sits there until i CTRL-C to stop it.
I dont understand what I am doing wrong and why nobody else is having this problem, when I expierence it on every computer, well it works somewhat on Windows. Can anyone Help me?
Thanks,
John
I'm not sure whether you already managed to solve this one, but I ran into the same problem (Ubuntu 10.10 / JavaSE6). After some investigation of the FreeTTS source I found the culprit, a deadlock, in com.sun.speech.freetts.audio.JavaStreamingAudioPlayer. This deadlock occurs when a Line is opened and the Line is of the type org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine (which is likely to be the default in Ubuntu 10.10 w JavaSE6). Since you'd always want to open a Line to get audio out, this deadlock will always occur.
The cause of this deadlock lies in the fact that in the JavaStreamingAudioPlayer an assumption is made about Line, namely that all LineListeners will be notified of a LineEvent of type open from the same Thread as Line.open() was called, or after the Line has been opened (and the call to Line.open() can return). This is not the case for the PulseAudioSourceDataLine; it first calls all LineListeners from the PulseAudio event Thread, waits for all of them to return and then returns from the open call. With the JavaStreamingAudioPlayer forcing synchronization around the call of Line.open() and the handling of a specific LineListener which task is to see whether the Line ís actually open, the deadlock occurs.
The workaround I chose for solving this problem is to implement an AudioPlayer which doesn't has this problem. I basically copied JavaStreamingAudioPlayer and altered the synchronization blocks on line 196 and line 646 ( full source for reference : http://www.javadocexamples.com/java_source/com/sun/speech/freetts/audio/JavaStreamingAudioPlayer.java.html ).
___: // This is the actual JavaStreamAudioPlayer source, not the fix
195: ...
196: synchronized (openLock) {
197: line.open(format, AUDIO_BUFFER_SIZE); // Blocks due to line 646
198: try {
199: openLock.wait();
200: } catch (InterruptedException ie) {
201: ie.printStackTrace();
202: }
203: ...
643: ...
644: public void update(LineEvent event) {
645: if (event.getType().equals(LineEvent.Type.OPEN)) {
646: synchronized (openLock) { // Blocks due to line 196
647: openLock.notifyAll();
648: }
649: }
650: }
651: ...
I removed both synchronization blocks and instead of ensuring both parts are mutually excluded I used a Semaphore to signal that the Line is in fact open. Of course this is not really a necessity since the PulseAudioSourceDataLine already guarantees being opened upon returning, but it is more likely to play nice when testing the same code on another platform. I didn't dive into the code long enough to say what is going to happen when you open/close/open the line by multiple Threads at the same time. If you're going to do this you are probably looking at a larger rewrite of the JavaStreamingAudioPlayer ;).
Finally, after you have created your new AudioPlayer you'll have to instruct FreeTTS to use your implementation rather than the default JavaStreamingAudioPlayer. This can be done by using
System.setProperty("com.sun.speech.freetts.voice.defaultAudioPlayer", "classpath.to.your.AudioPlayer");
somewhere early in your code.
Hopefully this all works for you.
I am a student who has been trying to make FreeTTS working on its Ubuntu for one week. And finally I found the answer here : thank you so much hakvroot !
Your answer was perfect but you did not put your implementation and this took me quite one hour to understand what was going on in the JavaStreamingAudioPlayer class. To help the other people like me who are not used in "diving" in a completely unknown Java code (I am still a student), I will put here my code and hope it will help other people :) .
First, a more detailed explanation : around line 152, the JavaStreamingAudioPlayer opens a Line. However this operation can require some time so before using it, it wants to check it is opened. In the current implementation, the solution used is to create a LineListener listening to this line and then to sleep (using the wait() method of the threads).
The LineListener will "wake up" the main Thread using a notifyAll() and will do this only when it receives a LineEvent of type "OPEN" which will guarantee that the line has been opened.
However as explained by hakvroot here the problem is that the notification is never sent because of the specific behavior of the DataLine used by Ubuntu.
So I removed the synchronized, wait() and notifyAll() parts of the code but as hakvroot, then your JavaStreamingAudioPlayer might try to use your Line before it is opened : you need to wait for the confirmation with a new mechanism to stop the JavaStreamingAudioPlayer and to wake it up later, when the confirmation arrived.
So I used the Semaphore which havkroot used (see Javadoc for explanations on this lock system) initiated with 1 stack :
when the line is opened it acquires one stack (so 0 remains)
when it wants to use the line it tries to acquire another (so it is stopped)
when the listener gets the event we are looking for, it releases the semaphore
this frees the JavaStreamingAudioPlayer who can go for the next part
do not forget to release again the semaphore so it has again 1 stack for the next line to open
And here is my code :
Declare a Semaphore variable :
private Semaphore hackSemaphore;
Initiate it in the constructor :
hackSemaphore = new Semaphore(1);
Then the first part to replace (see hakvroot to see where to put it) :
line = (SourceDataLine) AudioSystem.getLine(info);
line.addLineListener(new JavaStreamLineListener());
line.open(format, AUDIO_BUFFER_SIZE);
hackSemaphore.acquire();
hackSemaphore.acquire();
opened = true;
hackSemaphore.release();
And the second part :
public void update(LineEvent event) {
if (event.getType().equals(LineEvent.Type.OPEN)) {
hackSemaphore.release();
}
}
I guess had the same issue on Ubuntu 12.04/OpenJDK-6, the execution get stuck in Voice.allocate() with no errors and no response.
I tried using the Oracle/Sun JDK-6 instead of OpenJDK, and it worked fine.
P.S. Nice guide to install SunJDK on Ubuntu and configuring as default
http://www.devsniper.com/ubuntu-12-04-install-sun-jdk-6-7/
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.