I'm currently working on developing a program in Netbeans. Unfortunately, my program tends to freeze a lot, however I'm having trouble figuring out where the issue is. What I would like to do is simply have the debugger highlight the currently executing line inside my code (not inside libraries). Basically stop the code at any point without using a breakpoint. Is there any way to do this in the Netbeans IDE?
Alternately, is there anyway for me to cause a break point to activate (and so show a workable stacktrace) whenever one of my lines of code doesn't move on for a certain period of time?
Profiling does work to some extent, however, it doesn't let me examine variables or get a definitive stack trace.
I am writing this program in Java and I'm using the Java SE version of Netbeans 8.0.2.
Most IDEs (Eclipse, IntelliJ which I use) have an option to pause all threads in a program. Look under the debug menus probably in the same place things like step into, step out of etc reside. A quick Google search on Netbeans IDE says there should be an option under that menu named "pause" that will do what you want.
It will pause all threads of execution in your program. You will be able to examine the stack of each thread and from there should should be able to figure out where your code is hanging.
Related
I am really new to this and trying to get the JaamSim Tool running within Eclipse to run a Simulation for my Bachelors Thesis.
When ever I try to run the config im getting an libc++abi.dylib: terminating with uncaught exception of type NSException. The JaamSim Loading Window always opens for a brief moment and then closes again with the note "GUIFrame was unexpectedly closed"
I tried for days new and im out of ideas... installed the newest jdk from adoptopenjdk, as well as apache ant and maven. Also linked everything within the .bash_profile
I would be really grateful if somebody could guide me to an solution.I added the terminal log form eclipse here1
Btw I am on Mac if that helps
The "exception" you are encountering is not a Java exception. It is a native Objective-C NSException. The "NS" stands for NeXTSTEP. It is a shibboleth of the old NeXTSTEP OS that is the ancestor of OS X and macOS. I can understand your confusion because both Objective-C and Java use the term "exception".
The logs you posted are, likewise, not a Java stack trace but an NSLog based thread dump from the native frameworks that your Java graphics depend on. You cut off the text of the actual exception in the image you linked. I'm guessing you didn't recognize the format and so didn't see the helpful message.
I'm going to guess that full text of the NSException message was "NSWindow drag regions should only be invalidated on the Main Thread!" If this is the case, then I think your problem is likely caused by changing some graphics from a background thread.
System graphics, such as windows, alerts, etc. are managed in macOS through a framework called "Cocoa". NSWindow is a Cocoa object. One of the important rules of Cocoa (and most UI frameworks) is that you should only alter Cocoa objects (like NSWindow) from the main thread. Probably, you are making some alterations to your GUI (specifically, invalidating drag regions) from a background thread. Java doesn't have any inherent problem with this, but Cocoa does. So you get a native error instead of a Java error.
TL;DR: Only work with your GUI from the main thread. You are getting this error because you are changing the GUI from a background thread.
EDIT: After doing a little research.
It appears that this particular issue occurs with certain Java OpenGL libraries, in particular lwjgl. You can see a very determined but ultimately fruitless effort to fix the problem here. I'm not sure what OpenGL Java interface is used in JaamSim, but they documented this same problem as far back as 2018, saying
The bug turns out to be a known problem with the JOGL software we use for 3d graphics. Unfortunately, it will take a while to get a fix in place.
The same JOGL bug was documented again in 2019. There, it seems to be resolved. Their report of the fix was
encapsulated both construction fully to run on the Main-Thread
I'm not sure how much control over this you have. Your best bet is to start by adding the -XstartOnFirstThread flag to your java command. I would also check if anyone in your class has been able to make this work on a Mac. Sometimes, it's nice to do a quick impossibility check before wasting time.
This is intended to be a general-purpose question to assist new programmers who have a problem with a program, but who do not know how to use a debugger to diagnose the cause of the problem.
This question covers three classes of more specific question:
When I run my program, it does not produce the output I expect for the input I gave it.
When I run my program, it crashes and gives me a stack trace. I have examined the stack trace, but I still do not know the cause of the problem because the stack trace does not provide me with enough information.
When I run my program, it crashes because of a segmentation fault (SEGV).
A debugger is a program that can examine the state of your program while your program is running. The technical means it uses for doing this are not necessary for understanding the basics of using a debugger. You can use a debugger to halt the execution of your program when it reaches a particular place in your code, and then examine the values of the variables in the program. You can use a debugger to run your program very slowly, one line of code at a time (called single stepping), while you examine the values of its variables.
Using a debugger is an expected basic skill
A debugger is a very powerful tool for helping diagnose problems with programs. And debuggers are available for all practical programming languages. Therefore, being able to use a debugger is considered a basic skill of any professional or enthusiast programmer. And using a debugger yourself is considered basic work you should do yourself before asking others for help. As this site is for professional and enthusiast programmers, and not a help desk or mentoring site, if you have a question about a problem with a specific program, but have not used a debugger, your question is very likely to be closed and downvoted. If you persist with questions like that, you will eventually be blocked from posting more.
How a debugger can help you
By using a debugger you can discover whether a variable has the wrong value, and where in your program its value changed to the wrong value.
Using single stepping you can also discover whether the control flow is as you expect. For example, whether an if branch executed when you expect it ought to be.
General notes on using a debugger
The specifics of using a debugger depend on the debugger and, to a lesser degree, the programming language you are using.
You can attach a debugger to a process already running your program. You might do it if your program is stuck.
In practice it is often easier to run your program under the control of a debugger from the very start.
You indicate where your program should stop executing by indicating the source code file and line number of the line at which execution should stop, or by indicating the name of the method/function at which the program should stop (if you want to stop as soon as execution enters the method). The technical means that the debugger uses to cause your program to stop is called a breakpoint and this process is called setting a breakpoint.
Most modern debuggers are part of an IDE and provide you with a convenient GUI for examining the source code and variables of your program, with a point-and-click interface for setting breakpoints, running your program, and single stepping it.
Using a debugger can be very difficult unless your program executable or bytecode files include debugging symbol information and cross-references to your source code. You might have to compile (or recompile) your program slightly differently to ensure that information is present. If the compiler performs extensive optimizations, those cross-references can become confusing. You might therefore have to recompile your program with optimizations turned off.
I want to add that a debugger isn't always the perfect solution, and shouldn't always be the go-to solution to debugging. Here are a few cases where a debugger might not work for you:
The part of your program which fails is really large (poor modularization, perhaps?) and you're not exactly sure where to start stepping through the code. Stepping through all of it might be too time-consuming.
Your program uses a lot of callbacks and other non-linear flow control methods, which makes the debugger confused when you step through it.
Your program is multi-threaded. Or even worse, your problem is caused by a race condition.
The code that has the bug in it runs many times before it bugs out. This can be particularly problematic in main loops, or worse yet, in physics engines, where the problem could be numerical. Even setting a breakpoint, in this case, would simply have you hitting it many times, with the bug not appearing.
Your program must run in real-time. This is a big issue for programs that connect to the network. If you set up a breakpoint in your network code, the other end isn't going to wait for you to step through, it's simply going to time out. Programs that rely on the system clock, e.g. games with frameskip, aren't much better off either.
Your program performs some form of destructive actions, like writing to files or sending e-mails, and you'd like to limit the number of times you need to run through it.
You can tell that your bug is caused by incorrect values arriving at function X, but you don't know where these values come from. Having to run through the program, again and again, setting breakpoints farther and farther back, can be a huge hassle. Especially if function X is called from many places throughout the program.
In all of these cases, either having your program stop abruptly could cause the end results to differ, or stepping through manually in search of the one line where the bug is caused is too much of a hassle. This can equally happen whether your bug is incorrect behavior, or a crash. For instance, if memory corruption causes a crash, by the time the crash happens, it's too far from where the memory corruption first occurred, and no useful information is left.
So, what are the alternatives?
Simplest is simply logging and assertions. Add logs to your program at various points, and compare what you get with what you're expecting. For instance, see if the function where you think there's a bug is even called in the first place. See if the variables at the start of a method are what you think they are. Unlike breakpoints, it's okay for there to be many log lines in which nothing special happens. You can simply search through the log afterward. Once you hit a log line that's different from what you're expecting, add more in the same area. Narrow it down farther and farther, until it's small enough to be able to log every line in the bugged area.
Assertions can be used to trap incorrect values as they occur, rather than once they have an effect visible to the end-user. The quicker you catch an incorrect value, the closer you are to the line that produced it.
Refactor and unit test. If your program is too big, it might be worthwhile to test it one class or one function at a time. Give it inputs, and look at the outputs, and see which are not as you're expecting. Being able to narrow down a bug from an entire program to a single function can make a huge difference in debugging time.
In case of memory leaks or memory stomping, use appropriate tools that are able to analyze and detect these at runtime. Being able to detect where the actual corruption occurs is the first step. After this, you can use logs to work your way back to where incorrect values were introduced.
Remember that debugging is a process going backward. You have the end result - a bug - and find the cause, which preceded it. It's about working your way backward and, unfortunately, debuggers only step forwards. This is where good logging and postmortem analysis can give you much better results.
This is intended to be a general-purpose question to assist new programmers who have a problem with a program, but who do not know how to use a debugger to diagnose the cause of the problem.
This question covers three classes of more specific question:
When I run my program, it does not produce the output I expect for the input I gave it.
When I run my program, it crashes and gives me a stack trace. I have examined the stack trace, but I still do not know the cause of the problem because the stack trace does not provide me with enough information.
When I run my program, it crashes because of a segmentation fault (SEGV).
A debugger is a program that can examine the state of your program while your program is running. The technical means it uses for doing this are not necessary for understanding the basics of using a debugger. You can use a debugger to halt the execution of your program when it reaches a particular place in your code, and then examine the values of the variables in the program. You can use a debugger to run your program very slowly, one line of code at a time (called single stepping), while you examine the values of its variables.
Using a debugger is an expected basic skill
A debugger is a very powerful tool for helping diagnose problems with programs. And debuggers are available for all practical programming languages. Therefore, being able to use a debugger is considered a basic skill of any professional or enthusiast programmer. And using a debugger yourself is considered basic work you should do yourself before asking others for help. As this site is for professional and enthusiast programmers, and not a help desk or mentoring site, if you have a question about a problem with a specific program, but have not used a debugger, your question is very likely to be closed and downvoted. If you persist with questions like that, you will eventually be blocked from posting more.
How a debugger can help you
By using a debugger you can discover whether a variable has the wrong value, and where in your program its value changed to the wrong value.
Using single stepping you can also discover whether the control flow is as you expect. For example, whether an if branch executed when you expect it ought to be.
General notes on using a debugger
The specifics of using a debugger depend on the debugger and, to a lesser degree, the programming language you are using.
You can attach a debugger to a process already running your program. You might do it if your program is stuck.
In practice it is often easier to run your program under the control of a debugger from the very start.
You indicate where your program should stop executing by indicating the source code file and line number of the line at which execution should stop, or by indicating the name of the method/function at which the program should stop (if you want to stop as soon as execution enters the method). The technical means that the debugger uses to cause your program to stop is called a breakpoint and this process is called setting a breakpoint.
Most modern debuggers are part of an IDE and provide you with a convenient GUI for examining the source code and variables of your program, with a point-and-click interface for setting breakpoints, running your program, and single stepping it.
Using a debugger can be very difficult unless your program executable or bytecode files include debugging symbol information and cross-references to your source code. You might have to compile (or recompile) your program slightly differently to ensure that information is present. If the compiler performs extensive optimizations, those cross-references can become confusing. You might therefore have to recompile your program with optimizations turned off.
I want to add that a debugger isn't always the perfect solution, and shouldn't always be the go-to solution to debugging. Here are a few cases where a debugger might not work for you:
The part of your program which fails is really large (poor modularization, perhaps?) and you're not exactly sure where to start stepping through the code. Stepping through all of it might be too time-consuming.
Your program uses a lot of callbacks and other non-linear flow control methods, which makes the debugger confused when you step through it.
Your program is multi-threaded. Or even worse, your problem is caused by a race condition.
The code that has the bug in it runs many times before it bugs out. This can be particularly problematic in main loops, or worse yet, in physics engines, where the problem could be numerical. Even setting a breakpoint, in this case, would simply have you hitting it many times, with the bug not appearing.
Your program must run in real-time. This is a big issue for programs that connect to the network. If you set up a breakpoint in your network code, the other end isn't going to wait for you to step through, it's simply going to time out. Programs that rely on the system clock, e.g. games with frameskip, aren't much better off either.
Your program performs some form of destructive actions, like writing to files or sending e-mails, and you'd like to limit the number of times you need to run through it.
You can tell that your bug is caused by incorrect values arriving at function X, but you don't know where these values come from. Having to run through the program, again and again, setting breakpoints farther and farther back, can be a huge hassle. Especially if function X is called from many places throughout the program.
In all of these cases, either having your program stop abruptly could cause the end results to differ, or stepping through manually in search of the one line where the bug is caused is too much of a hassle. This can equally happen whether your bug is incorrect behavior, or a crash. For instance, if memory corruption causes a crash, by the time the crash happens, it's too far from where the memory corruption first occurred, and no useful information is left.
So, what are the alternatives?
Simplest is simply logging and assertions. Add logs to your program at various points, and compare what you get with what you're expecting. For instance, see if the function where you think there's a bug is even called in the first place. See if the variables at the start of a method are what you think they are. Unlike breakpoints, it's okay for there to be many log lines in which nothing special happens. You can simply search through the log afterward. Once you hit a log line that's different from what you're expecting, add more in the same area. Narrow it down farther and farther, until it's small enough to be able to log every line in the bugged area.
Assertions can be used to trap incorrect values as they occur, rather than once they have an effect visible to the end-user. The quicker you catch an incorrect value, the closer you are to the line that produced it.
Refactor and unit test. If your program is too big, it might be worthwhile to test it one class or one function at a time. Give it inputs, and look at the outputs, and see which are not as you're expecting. Being able to narrow down a bug from an entire program to a single function can make a huge difference in debugging time.
In case of memory leaks or memory stomping, use appropriate tools that are able to analyze and detect these at runtime. Being able to detect where the actual corruption occurs is the first step. After this, you can use logs to work your way back to where incorrect values were introduced.
Remember that debugging is a process going backward. You have the end result - a bug - and find the cause, which preceded it. It's about working your way backward and, unfortunately, debuggers only step forwards. This is where good logging and postmortem analysis can give you much better results.
I'm debugging a remote Java application using Intellij. I have defined several breakpoints, but Intellij suspends my application before hitting any of them. When I click 'Resume program', it continues to another arbitrary point that I did not mark. I have to do this several times until I finally get to the code I'm interested in. All of these unwanted pauses happen in library files. Is there a way to get Intellij to stop pausing at these places?
In Visual Studio, when debugging, one can drag the execution point (current instruction pointer, yellow dot) to another place in the current method.
This is impossible in IntelliJ, and some have stated it's generally impossible in Java. Why?
IntelliJ interacts with a running JVM through the standard Java debugging interface, so it can debug programs' against different JDKs. This does not support moving the execution point around as you describe.
It does let you wind the call stack back and perform a method call again. In IntelliJ, use the threads window to select a stack frame of a suspended thread and wind back to it. Then continue the thread to re-call the method at that point in the program.
Note: this will not roll back the state of the objects, so strange effects may occur.
In Eclipse, if you edit a method being debugged causing the debugged code to be updated the JVM rolls back execution to the first safe place. Usually this is the first line in that method.
It is very helpful in a debugging scenario.
You can tell the debugger to "Run to line" forward.
Java doesn't have a current execution pointer which can point to a random piece of code. Java assumes the order of execution is in the code, not something you would manipulate.
Perhaps you could explain why you would want to do this and we can let you know another way of achieving the same thing.