I have been developing a Java application using J2EE and a Derby database. My boss does most of the testing and I do most of the coding, but he has come to me with a strange problem. He claims that occasionally the Java application "crashes his computer".
To mention a few details, first let me say that I am currently working remotely, so I can't be around when these "crashes" happen. Second, I use OS X 10.6 and he uses Windows XP (SP3 I believe). The Java application in question does not use any JNI or anything weird except for an embedded Derby database. Lastly, he said it freezes everything in Windows (his mouse doesn't even move) -- it doesn't show up in the console like an uncaught exception would.
So, is it possible that my Java program is crashing his computer? I didn't think that Java code could have any system-wide effects outside of the JVM. Is this something that could possibly be the fault of my program, or should I just ignore it and attribute it to some problem with his computer?
For a Java application to crash the OS it runs on, there must be a bug in the JVM. That said there are situations that can give the same impression:
the Java application can grow its heap far enough that the OS starts to swap and other applications appear to slow down to a halt
the Java application can grab all CPU by one or more threads in a tight busy loop
If you can setup your testers' machine so that a heap dump can be triggered when the problem occurs, you can analyse that dump remotely. For instance with IBM's Java heap analyzer found on alphaworks.
There were cases before of crashes under windows on IBM Thinkpads (and other machines I am sure) due to a bad graphics driver. I'd suggest doing the usual thing of making sure the drivers are up to date just to be on the safe side.
While your code may not use JNI directly a lot of what happens under the hood can (anything that integrates with the underlying OS essentially). Which means drivers can be a big problem.
The other thing would to be sure that the most recent version of the Java is being used (if 1.6_17 isn't possible at last the latest version of the version of Java being used).
One other thing that has fixed random crashes for me is to re-seat the memory (unplug it and plug it back in).
he said it freezes everything in Windows (his mouse doesn't even move)
A user-mode application — whether Java or otherwise — can't do that against a modern OS like WinNT.
He either has a hardware problem, or a bad driver.
To crash the entire computer, try this:
public void crashComputer() {
while(true)
new Thread(new Runnable() {
#Override
public void run() {
while(true) {
crashComputer();
}
}
}).start();
}
public void crashJVM() {
while(true)
crashJVM();
}
The crashComputer function takes about 2 seconds to crash the entire computer. You can stop it from crashing by holding power button.
The crashJVM function crashed only the JVM by overloading the stack, causing a stack overflow (That's where the name of this website comes from).
WARNING: Use at your own risk. This will not damage your computer, but I'm not taking the blame if you forget to click save on a document or something.
Also check the page file space on the client (Windows/XP) system.
Point one: On my XP, SP3 system, when any program runs full tilt, it almost locks up the computer. When my anti-virus program checks for updates, everything else stops for all practical purposes, and it uses very little CPU (seems to be writing to disk all the time). My own infinite loops, using 100% CPU, have a similar effect. (Why the task manager does not get priority over a user program with "normal" priority I do not know.)
Point two: On any computer I've ever used, heavy paging will bring a program to an almost complete stop.
So start with an XP computer with 512Mb of real memory and 2000Mb of virtual memory. Write a Java program with 1400Mb worth of arrays and other data structures. Put in a loop that repeats several billion times and reads or writes to each byte in that 1400Mb on each execution. This program will not finish until long after the universe collapses in on itself. The computer will do nothing. I have not tried this and I do not intend to, but I will bet anything even the mouse won't move. Depending on the make of the computer, the only fix may be pulling the power plug out of the wall socket. (Note that technically, the computer has not crashed. Indeed, it is working just fine. But you are going to need to be patient. Move the mouse the day before you plan to click.)
The moral of this story is to avoid both XP and virtual memory, but if you have to deal with either, be aware of these problems.
Related
What happens within a Java application running locally on a PC when the power is switched off?(Plug pulled from wall).
Does Java have a way of handling an event like this or is it simply wiped from memory as soon as the power is killed?
Edit: To be a bit more clear, I'm wondering if Java as any way of safely exiting an application in the last moments of an unexpected shutdown.
Java programs (like all programs) require a CPU and memory to operate instructions. Both elements are complex electrical circuits, they cannot work without electricity.
The only thing you can do to persist the state of your application, is to write information regarding that state to disc. The Google File System uses this method to ensure not too much information is lost if one of their (usually inexpensive machines) goes down.
Short of this. No there is no way Java can handle a power out.
I'm a front end developer that's looking to get into some other languages such as Java or C++. I have an idea for a program and was just looking for an answer to something. What I would like to do is build a program and boot directly to that program. For example I have an old computer and I wipe the hard drive clean. So they is nothing currently on it. Not even an OS. I want to build a program that I can install to the hard drive that will boot straight into the program once started. Would this be considered an OS?
No you don't. Unless you want to spend many years, writing drivers for your graphics card, harddisk controller, usb controller, dma controller and all the other hardware your computer have.
What you want is a minimal operation system, which include just the kernel, and a runtime library and which start your program and nothing else on startup. A minimal Linux such as linux from scratch or bsd would be a good starting point.
First of all you need to decide your your program needs what. I mean should operate in Protected mode or the routine you have is tiny, so it is enough to run before entering protected mode (i.e. in real mode).
Here you can do three things
Modify bootloader to jump the execution to your code . Then Your code can resume normal os initialization.
Modify your os kernel early initialization code So that it executes your code before entering protected mode
I think your code will not be harmed if a bit of os portion is running. So you can write your routine before full kernel initialization.
Now note that for the later two point you need to modify your kernel, which is not easy (not even always possible)
Now the problem in first approach: Nothing will be ready for you, not even a regular c library or divice drivers , so you have to write every raw bit of code by hand which is crude.
This is off course not possible in java. Because the jvm will not be ready for you.
Now practically: there are lot of tiny os available, use one of them and modify as per your need. use this link to get a complete list of what is available for you.
First, Java is right out. You cannot possibly do this in Java without enormous amounts of tool-building. Java is not suited for this task at all.
You can do it in C++ or C. The search terms you are looking for is operating system development. This would probably not technically be considered developing an Operating System since it wouldn't run other programs, but the information about how to get through the boot-up procedure and establish a minimal environment are going to be most easily found in the category of operating system development. Some reasonable starting resources for that can be found at the OS Dev Wiki.
Alternately, you could take an existing small open-source OS and modify what it does after the boot-up sequence completes. If your program is intending to do anything more than just use the keyboard and the screen in text mode, there need to be device drivers. Thus, depending on the project, changing an existing OS may be the easiest route because you won't need to write your own device drivers for any devices you want to use.
Java can't run without Environment. If you want to run you program on you machine without OS, Java is a wrong choice.
C++ program can run without OS, but it's difficult to write a bootable program in C++.
If you want to write your own bootable program, you should use assembly for boot and load function, with some knowledge to use hardware in low level.
You have to have an operating system, so your program would be the operating system (or you would have to use another one and write it for that). It's certainly possible in C++, but it's not really possible to write an operating system in java.
Unless you want write something in (for example) Open Firmware and Forth or say a ROM BASIC. You'll probably qualify as a boot loader. Your application may qualify as an operating system. In my opinion, and a modern context, it entirely depends on how much functionality it provides to hosted applications. I'm not sure that something like FreeDOS would be considered an operating system (no pre-emptive task scheduling or GUI for example) given modern computers (I don't care to argue the point either way).
I have a java application that I run from eclipse 3.5.
My OS is WinXP(SP2) and the JRE version is 6.05.
I run the application on two identical computers (or so I think) but the application behaves differently on each computer.
The computers are the same Dell Optiplex model with the same amount of memory and have the same GPU.
On the first computer, the application runs flawlessly. However, on the second one the application freezes for a couple of minutes and then returns to run normally.
The strange thing is that the CPU usage on the second computer is not high at all. It seems as though my application does not receive any CPU for no apparent reason.
Computers should be deterministic so I assume there must be some difference between the machines but I don't know where to look.
I would love some ideas on where the problem might be.
Thanks,
Yoav.
I've found the problem.
The application that was unresponsive was run in debug mode.
Sorry to have wasted your time...
It may help you to get a Thread Dump when the app freezes. This will hopefully tell you exactly what is holding you up (i.e. waiting for IO somewhere).
Well, I would first update your JRE version as there are newer versions now.
As for both computers being identical, are they really identical? I find it difficult to believe that both have the same exact software and setup and that anything you have done to one, you have always done to the other. If this is indeed the case, you may want to try to debug your application on the second machine (the one that hangs) and find out specifically where it hangs.
It may also help us if you give more information about your application. The problem may not be your computer at all if the application is doing things like web access, network access, etc.
So both computers have nearly identical hardware. A few other things to check
Do they both have Eclipse 3.5, WinXP(SP2) and JRE 6.05 installed?
And behave differently when run from within Eclipse (on both machines or on one run from command-line)?
Is this reproducible? If yes When does it happen? On startup? Or on some specific action?
Does the program have a GUI?
Is there maybe some kind of virus scanner or another comparable software installed on one of the machines which could delay the program
Is networking, file acccess, multithreading involved?
I can think of two non-application possibilities:
Memory Paging. There's something extra happening on the slow machine, so your JVM is not getting a fair share of CPU time. A large daemon process or some such.
Network access. Your app is making some kind of network call and it's glitching or timeing out. Perhaps going and fetching some XML schema, perhaps a disk acesss to a mounted drive.
I've seen all manner of weirdness when apps attempt to access hosts by name and DNS is not well. One machine has an etc/host entry the other does not. Even each machine might want to resolve itself.
I've got a little game that a friend and I are writing in Java. It's kind of badly coded and we're working on refactoring it, but that's not really the issue right now. We both have 64 bit machines and I guess before we were both using 32 bit JDKs, but recently I had some problems and so I removed all JDKs and installed the latest 64 bit JDK, and I'm not sure when but my friend is also now running a 64 bit JDK. Our game was running fine in the 32 bit JDK, but with the 64 bit version the game won't start. I've been trying to debug it with eclipse, but it's been a bit of a pain.
Our game is networked and multithreaded, and I think we have some issues with how we synchronized things (I didn't fully understand the whole idea of synchronization when I was writing it before) eg. we had made our run() methods synchronized which has no effect, but despite the stupidities of large parts of our code the stuff still runs on a 32 bit JVM (Windows and Linux).
The game starts up where one person hosts a game, and then others can join until the host decides to start the game. It then sends a prompt to all the players, asking if they want to start, and if all say yes the game starts. What is happening on the 64 bit JVM is that it sends the message, but it seems like the response is getting lost or something, or the server isn't counting correctly that everyone has OKed because the game doesn't actually start. Actually, the host gets a few more messages that the other player(s) don't get and gets a little farther in starting the game, but the server seems to get stuck somewhere.
Any ideas what might be the problem? Our code is up on github if anyone wants to take a look. I'd be extremely happy if you did, but I don't expect anyone to wade through our ugly code. Thanks!
By the way, we are both running on 64 bit Windows Vista and JDK 1.6 u12 and u14, but we also run Linux although I haven't been able to test it on a 64 bit Linux JVM yet.
Oh, more details about why I'm pretty sure it's a 64 bit JVM isssue:
So we were working on this basically in the fall semester, and stopped working on it for a while. After 6 months we pick it up again, stagger at our horrid code, and start trying to clean it up. Then we realize that neither of us can run it properly. I try to find a revision that works, but I get to the last revision from before we started working on it this summer and it's still not working. I then even checked some binaries (.jars) that I had compiled before and even the earliest revision I have doesn't work on the 64 bit JVM. I then checked in a 32 bit Linux VM running the Sun JDK1.6 JVM, and it worked fine. Thus, I'm pretty sure it's a 64 bit problem since before the same binaries were working perfectly.
I've also noticed that Vista was assigning IPv6 addresses to my sockets for some reason, when connecting to a server on my own machine (0:0:0:0:0:1 instead of 127.0.0.1) but I fixed anything that was IPv4 specific and it's still not working.
I actually have just created another problem on my github repository which is a whole other tale of woe, so I can't test my latest build on another machine right now. But the last build before refactoring works fine on a 32 bit JVM with a dual core, so it doesn't look like a race condition.
Oh, another thing, exact same problem running under OpenJDK 6 64 bit under Linux. I'm guessing it's a race condition that the 64 bit version somehow brings out.
The game starts up where one person
hosts a game, and then others can join
until the host decides to start the
game. It then sends a prompt to all
the players, asking if they want to
start, and if all say yes the game
starts. What is happening on the 64
bit JVM is that it sends the message,
but it seems like the response is
getting lost or something, or the
server isn't counting correctly that
everyone has OKed because the game
doesn't actually start. Actually, the
host gets a few more messages that the
other player(s) don't get and gets a
little farther in starting the game,
but the server seems to get stuck
somewhere.
This sounds like it might be a race condition, i.e. flawed or missing synchronization. Since race conditions are timing-dependant, almost anything (including switching JVMs) can cause them to manifest.
I'd stop worrying about 64bit vs 32bit and try to diagnose the actual problem. Since it involves multiple machines, it's unfortunately going to be very hard (which is generally the case with race conditions).
The best way to do it is probably to make sure all machines have synchronized clocks using NTP, and then log the sending, receiving and processing of messages with millisecond timestamps so you can see where messages get lost or aren't processed properly.
We found out what the issue was. There was a loop in one part where a thread waited on something to become ready that another thread was working on, except it was just a while(!ready){} loop. It seems like in the 64 bit JVM threads don't get preempted or something, because in the 32 bit JVM this loop would get preempted and then the other thread would finish and set the variable to true, but not in the 64 bit JVM. I understand now that we should have used wait/notify and locks to do this, but at least temporarily throwing a sleep() in there fixed it. Not exactly a race condition, more of a quirk of the threading model it seems, so I'm not accepting any of the other answers since they didn't answer the question I asked.
Are you running with the java process with the -d64 option? If not, then I'm pretty sure you're still running the JVM in 32-bit mode, and your issue may be related to the environment or the OS instead of the bitness.
I would not expect 64 vs. 32 to cause any issues in this case, threading is way more likely to be your cause
kudos for using raw sockets, but they're very tricky to get correct. Consider using a library for your network stack, like Apache Mina, unless of course the goal of the project is to write your own socket code. Definitely read over the quick start guide. It's text-based protocol maps directly to what you're using.
Side note: sticking synchronized on every method and using finalize are symptoms of bad things / code smells
I'm trying to get to the bottom of a problem with our Java applet based program. It quite regularly seizes up with an unresponsive GUI (or a white screen). This of course only happens when deployed at a customer site :-(. They are running a version of the Sun JVM in 1.5 series (not sure the exact release).
We have a theory that it's to do with the applet running out of heap space - does that sound plausible? The other thing that I have set up on my machine is disabling direct draw, but that was mainly to avoid weird artefacts on other applications.
They are seeing the problem on Citrix and on regular PCs, but obviously there is a limit to what the users on Citrix can do.
Any suggestions?
Running out of heap space should cause an OutOfMemoryError to be thrown. This case sounds like a typical deadlock. To find where that is you want a stack dump of all the threads. IIRC< you can do it through the console, or from IIRC 1.6 the JDK includes jps and jstack.
First of all ensure the customer uses the latest release of the JVM they are using, and make them enable the Java console inside their browser (this requires some research from you).
Then when it happens again, tell them to look at the console window and cut-paste the contents in a mail to you.
In order to solve the problem, you must first be able to reproduce the problem. You will need an identical system in order to troubleshoot this, making one change at a time while keeping everything else equal to determine the cause(s).
Just to add to this answer (to build the knowledge base as I'm currently looking into this).
There's (at least) 2 distinct white screens related to applets.
Deadlock (as mentioned by Tom) - area will not refresh when you drag a window in front of it, so you get the strange tails left effect.
VM crash - area will become white, Java VM closes (search for hs_err_pid*.log, location dependent on browser)