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
Related
I tried to make a Minecraft Server, using the suggestions I've seen people telling others to use the Paper API. So I got all the files, and I allocated 512 MB of ram to it (using -Xmx512M), and it runs completely fine! But it bumps into the limit of RAM too much, so I tried to push it to 3 GB (using -Xmx3G). (A bit excessive, for what I'm using it for, but it'll help me sleep at night, knowing I have a server that's not running into issues) but then I run into the problem where Java simply does not want to start.
I experimented a bit, found that anything higher than 1.5G and Java starts having problems. Could not reserve enough space for 3145728KB object heap
.
So I went looking around, and found people saying "Add an Environment Variable to the System Variables with _JAVA_OPTIONS and -Xmx3G" and whatever, and it appears to not change anything for me. Java still doesn't want to start. Does anyone know how this is? I can't seem to update my Java to any higher version, assuming mine was outdated. So it can't be an update, and not everyone runs into this issue because a server manager once told me their server ran with 10GB of ram.
I'd ask them, but I've lost contact, so I'm asking here instead.
You may be using a 32-bit Java installation. Check which Java is being executed and install/use the 64-bit version.
https://java.com/en/download/manual.jsp
Make sure you're running 64 Bit Java. Otherwise, go to the link above and get the Windows 64-Bit Offline download. then run that. Immediately fixed it for me.
Full disclosure: this is a federal computer/system so I have limited capability to make significant changes, but our federal "Enterprise" service desk of course does not know what is happening, so, I'm here.
I have a 64 bit operating system set up due to setting up ODBC connections to work with various programs which includes R 64 bit (this is the set up we were told we needed for all the systems to work). I of course also need Java 64 bit in order to use many of the R packages available nd have installed 64 bit Java multiple times, while sometimes removing and sometimes leaving 32 bit Java installed. Everything works fine for a while and I'm able to use the packages requiring Java by setting the Java environment path as necessary. No problems there.
The issue comes a few hours/one day later when my entire system shuts down with no notification at all (all programs just shut down while I'm actively working in them). The system reboots itself, 64 bit Java is uninstalled and 32 bit Java is reinstalled (regardless of whether I had uninstalled the 32 bit version or not) and I'm left to reinstall 64 bit, which works for a few hours before the whole process repeats itself.
I can't find anything anywhere for the same issue so... Anyone have any ideas? Our service desk basically just told me our systems only force reboots for Windows updates and and don't have any idea what is happening.
Edit: This is Java 1.8.0_111 although I've had the same issue with previous updates of Java 8.
Edit 2: No one else is having the same issue and are having no trouble with 64 bit Java on their computers. I'm special.
I've got an applet which does something which gets Windows 7 to freeze completely, the mouse pointer no longer responds, ctrl-alt-del no longer works etc.
When I open the task manager, it doesn't show any significant CPU load or excessive usage of memory.
The freeze sometimes happens when debugging on Eclipse as well, but not always.
I'm not quite sure where I should set breakpoints yet since it's a pretty big GUI application.
Could this be a bug in the JVM? Isn't it supposed to be impossible for an applet to do something like this?
Edit: To answer my own question, I found the bug in Eclipse, and it seems that the call to Toolkit.getDefaultToolkit().getSystemClipboard().getContents(null) gets the whole system to freeze, which is pretty surprising since the Excel file is only 1 MB. Maybe the clipboard isn't really designed for situations like this.
Use jStack to generate a Thread Dump. That way you will know what the code is doing. To use it just:
C:\your_java_bin_folder> jstack -l <process-id>
You can get the process id from the Task Manager. jStack is part of the jdk (as far as I know since 1.5).
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.
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.