While doing some homework that works with some swing gui components, my program started crashing seemingly at random. That is, it starts, runs for a short time, and then crashes. I don't get any errors in the console, it's just a straight up crash.
I don't doubt that it is something I wrote, and I'm more than happy to show code if anyone wants to look at it, but is there anything that I can do myself to track down what might be the cause of my crashes?
Some other information that might be useful:
I'm using eclipse, and the debugger doesn't seem to do anything that helps me with this (program still crashes).
I didn't notice any issues like this until I started to add event handling.
I'm using Windows 10.
Occasionally, nothing is drawn in the window I create. Exiting and then running the program again will cause it to work.
Some possible heuristics:
Crashes that occur seemingly at random suggest incorrect synchronization; look for event dispatch thread violation using one of the approaches cited here.
Verify that all exception handlers produce diagnostic output; run from the command line to ensure that diagnostic output has not been inadvertently redirected.
Try running under the aegis of a different debugger, e.g. NetBeans.
Try running under the aegis of a profiler.
Try a different version of the JDK/JRE.
Try a different host OS.
Related
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 not entirely sure how to word this question, so I apologize for the vague title. My problem is that I've encountered a bug that causes the program to crash. However, it only occurs when I don't have a debugger attached to the process. I'm 95% certain the crash is related to the frame rate of the program, and since the debugger slows down the program so much, the crash can't occur while it's running.
So, I was wondering if there was any way to attach a debugger to the program after it crashes, or possibly speed it up in some way by disabling unnecessary features up until the crash. I'm not entirely sure either are possible though, from what I've been able to find, so if anyone has any suggestions as to what else I can do to debug the program, please say so.
Just answering my own question so it doesn't remain unaccepted. Answer was gotten from the comment by CodeChimp.
The issue was that the I had several breakpoints throughout my program that were causing the slowdown. When I disabled all other breakpoints besides a single uncaught exception breakpoint, the debugger was able to run fast enough to catch the crash.
I have scenario where I am scheduling task at fixed duration repetitively.Fixed delay is generated by calling start method of another class that implements runnable interface using Thread.sleep(long ms ) method.
But when I test this application in my local pc it is working.But when I run this application in ibm blade server(64 bit) having OS(Windows server 2008 R2) it do not work as desired. It do not come out of sleep method.
Kindly suggest the solution?
Thank You in Advance.
There is not much information in your question to see what the problem is. Thread.sleep should either return or throw an exception. Maybe something different is happening. For example, an exception has occurred, caught and forgotten, or you have a deadlock somewhere. Anyway, different versions of Java sometimes have subtle differences causing bugs. You will have to investigate the problem yourself.
Try debugging the application. When it hangs, press Pause and examine all threads to find the hanging one.
If you can't install a debugger on the server, add System.out.println in every reasonable place of the code; reading the output in the console, you will probably be able to track down the issue.
If you can't launch the application with console, create a text file and write the messages to it. Don't forget to flush it every time.
I've built a RCP-based application, and one of my users running on Windows XP, Sun JVM 1.6.0_12 had a full application crash. After the app was running for two days (and this is not a new version or anything), he got the nice gray JVM force exit box, with exit code=1073807364.
He was away from the machine at the time, and the only thing I can find near that time in the application logs was some communication with the database (SQL Server by way of Hibernate). There's no hs_ files or anything similar as far as I can tell. Web searching found a bunch of crash reports with that exit code in a variety of applications, but I didn't see any fundamental explanation of what causes it.
Can anyone tell me what causes it? Is there additional information likely to have been dumped that could prove useful?
From what I can tell, this error code (0x40010004) arises in all sorts of situations, with (as you noted) no obvious common thread.
However this page says "0x40010004" means "the task is running"! So, I would surmise that the correct way to interpret it is as saying "this tasked has exited in a way that prevented it setting a proper exit code".
I don't know if this will help, but I would try looking in the Windows Event logs to see if the problem is being reported there.
I've written a Java app that allows users to script mouse/keyboard input (JMacro, link not important, only for the curious). I personally use the application to automate character actions in an online game overnight while I sleep. Unfortunately, I keep coming back to the computer in the morning to find it unresponsive. Upon further testing, I'm finding that my application causes the computer to become unresponsive after about 10 minutes of user idle time (even if the application itself it simulating user activity). I can't seem to pin-point the issue, so I'm hoping somebody else might have a suggestion of where to look or what might be causing the issue.
The relevant symptoms and characteristics:
Unresponsiveness occurs after user is idle for 10 minutes
User can still move the mouse pointer around the screen
Everything but the mouse appears frozen... mouse clicks have no effect and no applications update their displays, including the Windows 7 desktop
I left the task manager up along the with the app overnight so I could see the last task manager image before the screen freezes... the Java app is at normal CPU/Memory usage and total CPU usage is only ~1%
After moving the mouse (in other words, the user comes back from being idle), the screen image starts updating again within 30 minutes (this is very hit and miss... sometimes 10 minutes, sometimes no results after two hours)
User can CTRL-ALT-DEL to get to Windows 7's CTRL-ALT-DEL screen (after a 30 second pause). User is still able to move mouse pointer, but clicking any of the button options causes the screen to appear to freeze again
On some very rare occasions, the system never freezes, and I come back to it in the morning with full responsiveness
The Java app automatically stops input scripting in the middle of the night, so Windows 7 detects "real" idleness and turns the monitors into Standby mode... which they successfully come out of upon manually moving the mouse in the morning when I wake up, even though the desktop display still appears frozen
Given the symptoms and characteristics of the issue, it's as if the Java app is causing the desktop display of the logged in user to stop updating, including any running applications.
Programming concepts and Java packages used:
Multi-threading
Standard out and err are rerouted to a javax.swing.JTextArea
The application uses a Swing GUI
awt.Robot (very heavily used)
awt.PointerInfo
awt.MouseInfo
System Specs:
Windows 7 Professional
Java 1.6.0 u17
In conclusion, I should stress that I'm not looking for any specific solutions, as I'm not asking a very specific question. I'm just wondering if anybody has run into a similar problem when using the Java libraries that I'm using. I would also gladly appreciate any suggestions for things to try to attempt to further pinpoint what is causing my problem.
Thanks!
Ross
PS, I'll post an update/answer if I manage to stumble across anything else while I continue to debug this.
Update: my app involved multi-threaded processes each initializing their own Robot objects and creating input events asynchronously. I refactored the app to only contain one Robot singleton object, but the different processes still asynchronously invoke input commands. As far as I can tell, this did not change the behavior of my app. My next step might be to created a synchronized wrapper around the Robot singleton to see if that helps, but given the symptoms, I don't know why it would.
I've had problems using the Robot class before. I forget exactly what I've done, but it has caused the computer to lock up and I've been forced to reboot.
I'm not familiar with the vagaries of Robot, but Uncaught exceptions in GUI applications can produce very odd results as the event dispatch thread dies and restarts. You might get some ideas from How uncaught exceptions are handled.
This can happen if u activated any screen saver or some thing like that, then this robot actions will stop working
i got this problem in the following way
i am having some GUI based applications and i written some test code based on Robot class.
but if i activated screen saver in my system this test cases stopped working...
please check any such scenarios are there in your case
for Ross, I am pretty sure that you have a policy problem which mean that you don't have permission and getting block by win7. To get this permission you must create a policy and that is a big of a story. Check what info you can get from sun website.
For the others if your program stops working after some period of time it might be that you are not handling all of the exception in your program right. Try to get the line when it stops: you can do it by just sending a line of text to the system console, and rewrite it to get the performance you want.
For the rest check your code and check it good very good to see that you are not getting into a dead lock which might stuck your pc if it has something with it.
Also check to see the CPU usage and see if your program is overloading it if it does your CPU temperature control will restart or turn off your PC automatically.
If i didn't hit the problem, let me know; if you solved the case please let me know what you did.
We have two machines with almost exactly same behavior with Java applications.
One is with Windows 7 64 bit, where Eclipse 64bit and Java 6 (64bit) is causing exactly same freeze.
Other is with Windows 7 32 bit and Java application utilizing a lot of CPU and disk activity causing freeze.
Both machines are notebooks from Toshiba with modern CPU's (Core 2 Duo).
Also both machines have NOD32 anti virus installed.
Standard apps (Office, Skype, Firefox,...)
We seem to tracked down problem to NOD32. When we disable NOD32 it seems that beahaviour does not occure anymore.
I want to point out that I don't think it's NOD32 itself, but some combination of Windows 7, Java JDK and NOD32.
I ran into a similar issue on Mac OS X 10.6.7 but it was not freezing entire system but the entire java process where my application was running in, and interesting at random basis. Workaround for this was call:
Toolkit.getDefaultToolkit();
Before create any Robot, in example:
public static void main(String[] args) {
Toolkit.getDefaultToolkit();
//Blah blah
}
Same call is made in init method at Robot class so seems where the problems are coming from, this is stupid and does not make a lot sense to me but works perfectly now :)