A few months ago I created a Java application which calculates chess ratings. I only ever tested it on my computer, but the program worked as expected.
I only just found out that on certain operating systems, the program doesn't work as it should. I've included a picture of the incorrect output on Windows 7 whereas this is what I get on Windows 8. (The player's rating should decrease since he scored only 1.5/5 against lower rated opposition). It seems that the program does not allow the player's rating to decrease.
Can anyone point me in the right direction as to why the program is behaving differently between these two versions of Windows? I was unable to find any explanation here on SO or anywhere else.
I think the most plausible explanation is that the Windows 7 version has a different argument there in the field 2: 2068 whereas Windows 8 has 2048.
Firstly, here are a couple of things that will NOT be the cause.
Arithmetic does not behave differently between Java on Windows 7 and 8. If you are running the same (single-threaded) algorithm with the same inputs, then the outputs should be the same.
Arithmetic does not change on 32-bit versus 64-bit JVMs.
So what could it be? Assuming that it is the same JAR, then it is likely that the algorithm doesn't change. So here are a couple of possibilities.
It could be a result of different inputs. Without looking at the algorithm, we can't exclude the possibility that there is something about it that makes it sensitive to the inputs in an unexpected way.
If there was a race condition in your code, you could find that that some aspect of your program doesn't work properly on some Java platforms ... due to differences in CPU speed, memory architecture and / or thread scheduling.
That's about as precise an answer as you could possibly get ... without looking at your code. So I think you are going to have to debug this yourself.
Get access to some Windows 7 machine that exhibits the problem.
Run the application with a debugger attached to see if the problem recurs under those conditions. If it does, then debug in the normal way to figure out why the algorithm is not working.
If attaching a debugger (and setting breakpoints) changes the way the program behaves (i.e. it makes the problem "go away") then you have evidence that points to a race condition of some kind.
For future Googlers, the problem wasn't with Java; it was a problem with newlines in a text file from which my program was reading data. For some reason, the "\n" character separating values in my text file was not showing up in Windows 7 but worked fine in Windows 8. Very strange but glad that it's fixed!
Related
I recently started java programming. I was told BlueJ is one of the best IDE's out there to start with. It worked for about a week. But then there was this one specific program, very simple program, just divided a few numbers to get an idea about associativity. It showed me an error that division by 0 is not possible. Right after that, each program i did produced no output what so ever. As in the output terminal will remain blank, completely. At the same time, my whole OS starts to slow down, even down to the file explorer. I have no idea whats causing this, since i have not changed the settings nor tampered with it.
Also i thought maybe it could be because of the complexity of the program, like a loop or something. Hence, i tried a simple hello world program, just to display a text, that's all. Even a simple program like that didn't produce an output.
What could be causing this problem ?
Operating system : Windows 10 Pro (64 bit)
RAM : 8 GB DDR3
Bluej : Version 4.1.0
I would uninstall and reinstall BlueJ, as well as doing the same with Java. This is probably the best method to resolve.
I am a newbie to Java and I have this app developed by someone else which is having some issues.
This Java app works well on windows xp 32 bit, but there is a delay while running on 64 bit windows 2008 R2 server. I have asked the customer to make sure that they are running the 32 bit version of JRE. I have checked the traces for the application and the application has an issue while calling a synchronized block always. This synchronized block adds the data into a queue from which it is picked up by some other process. I have checked the traces if some other process is using the block but it isn’t. The only confusing part is that the same app runs perfectly on windows xp 32 bit.
After googling I came to know that there are threading issues in win64
Help me with this.
This isn't exactly an answer, but it might be of some help and it's more than a comment:
Most likely your 64 bit machine has more cores than the 32 machine, making it more likely that two or more threads really will run at the same time and any synchronization problems that never, or rarely, arise on the 32 will quickly pop up on the 64. Also, newer machines tend to execute more instructions at once than older machines. Both types reorder them as they do so. (Also, compilers often reorder the code.) So the 64's are a bit worse to start with, and when you throw in the more extensive, real multithreading the problems multiply.
(This can work the other way: the many-core machines tend to run threads in a predictable order, where a single core machine can wait many minutes to run something you expected would be executed immediately.)
I've usually found the best way to fix bugs is to stare at the code and make sure everything is precisely right. (This works better if you know when something is precisely right.) Failing that, you need logging messages that only print out when they're useful (it's hard to sort through a billion of them). You seem to have no trouble reproducing your problems (which almost makes me think it may not be a multithreading problem at all), which should make it a bit easier to figure out.
An application that we have recently started sporadically crashing with a message about "java.lang.OutOfMemoryError: requested 8589934608 bytes for Chunk::new. Out of swap space?".
I've looked around on the net, and everywhere suggestions are limited to
revert to a previous version of Java
fiddle with the memory settings
use client instead of server mode
Reverting to a previous version implies that the new Java has a bug, but I haven't seen any indication of that. The memory isn't an issue at all; the server has 32GB available, and Xmx is set to 20 while Xms is 10. I can't see the the JVM running out of the remaining 12GB (less the amount given to the handful of other processes on the machine). And we're stuck with server mode due to the nature of the application and environment.
When I look at the memory and CPU usage for the application, I see constant memory usage for the whole day, but then suddenly right before it dies CPU usage goes up to 100% and the memory usage goes from X, to X + 2GB, to X + 4GB, to (sometimes) X + 8GB, to JVM death. It would appear that there is maybe cycle of repeated array resizing going on in the JIT compilation.
I've now seen the error occur with the above 8GB request and also 16GB requests. All times, the method being compiled when this happens is the same. It is a simple method that has non-nested loops, no recursion, and uses methods on objects that return static member fields or instance member fields directly with little computation.
So I have 2 questions:
Does anybody have any suggestions?
Can I test out whether there is a problem compiling this specific method on a test environment, without running the whole application, invoking the JIT compiler directly? Or should I start up the application and tell it to compile methods after a much smaller call count (like 2) to force it to compile the method almost instantly instead of at a random point in the day?
#StephenC
The JVM is 1.6.0_20 (previously 1.6.0_0), running on Solaris. I know it's the compilation that is causing a problem for a couple reasons.
ps in the seconds leading up to it shows that a java thread with id corresponding to the compiler thread (from jstack) is taking up 100% of the CPU time
jstack shows the issue is in JavaThread "CompilerThread1" daemon [_thread_in_native, id=34, ...]
The method mentioned in jstack is always the same one, and is one we wrote. If you look at sample jstack output you will know what I mean, but for obvious reasons I can't provide code samples or filenames. I will say that it is a very simple method. Essentiall a handful of null checks, 2 for loops that do equality checks and possibly assign values, and some simple method calls after. All in all maybe 40 lines of code.
This issue has happened 2 times in 2 weeks, though the application runs every day and is restarted daily. In addition, the application wasn't under heavy load any of these times.
You can exclude a particular method from being JIT'ed by creating a file called .hotspot_compiler and putting it in your applications 'working directory'. Simply add an entry in the file in the following format:
exclude com/amir/SomeClass someMethod
And the console output from the compiler will look like:
### Excluding compile: com.amir.SomeClasst::someMethod
For more information, read this. If you're not sure what you're applications 'working directory' is, use the
-XX:CompileCommandFile=/my/excludefile/location/.hotspot_compiler
in your Java start script or command line.
Alternatively, if you're not sure its the JIT compilers fault, and want to see if you can reproduce the problem without any JIT'ing, run your Java process with -Xint.
Okay, I did a quick search and found a thread on sun java forums that discusses this. Hope it helps.
Here another entry on Oracles forum. Similiar sporadic crash. There is one answer where one solved the problem by reconfiguring the gc's survivor ratio.
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.
When a Java VM crashes with an EXCEPTION_ACCESS_VIOLATION and produces an hs_err_pidXXX.log file, what does that indicate? The error itself is basically a null pointer exception. Is it always caused by a bug in the JVM, or are there other causes like malfunctioning hardware or software conflicts?
Edit: there is a native component, this is an SWT application on win32.
Most of the times this is a bug in the VM.
But it can be caused by any native code (e.g. JNI calls).
The hs_err_pidXXX.log file should contain some information about where the problem happened.
You can also check the "Heap" section inside the file. Many of the VM bugs are caused by the garbage collection (expecially in older VMs). This section should show you if the garbage was running at the time of the crash. Also this section shows, if some sections of the heap are filled (the percentage numbers).
The VM is also much more likely to crash in a low memory situation than otherwise.
Answer found!
I had the same error and noticed that others who provided the contents of the pid log file were running 64 bit Windows. Just like me. At the end log file, it included the PATH statement. There I could see C:\Windows\SysWOW64 was incorrectly listed ahead of: %SystemRoot%\system32. Once I corrected it, the exception disappeared.
First thing you should do is upgrade your JVM to the latest you can.
Can you repeat the issue? Or does it seem to happen randomly? We recently had a problem where our JVM was crashing all over the place, at random times. Turns out it was a hardware problem. We put the drives in a new server and it completely went away.
Bottom line, the JVM should never crash, as the poster above mentioned if your not doing any JNI then my gut is that you have a hardware problem.
The cause of the problem will be documented in the hs_err* file, if you know what to look for. Take a look, and if it still isn't clear, consider posting the first 5 or 10 lines of the stack trace and other pertinent info (don't post the whole thing, there's tons of info in there that won't help - but you have to figure out which 1% is important :-) )
Are you using a Browser widget and executing javascript in the Browser widget? If so, then there are bugs in some versions of SWT that causes the JVM to crash in native code, in various Windows libraries.
Two examples (that I opened) are bug 217306 and bug 127960. These two bug reports are not the only bug reports of the JVM crashing in SWT, however.
If you aren't using the Browser widget then these suggestions won't help you. In that case, you can search for a list of SWT bugs causing a JVM crash. If none of those are your issue, then I highly recommend that you open a bug report with SWT.
I have the same problem with a JNLP application that I have been using for a long time and is pretty reliable. The problem started immediately after I upgraded from Windows 7 to Windows 10. According to my investigation, it is most likely a bug in Win 10.
The following is not a solution, but an ugly workaround. In jre/bin directory, there is javaws.exe. If I right-clicked /Properties/Compatibility and ticked Run this program as an administrator, the JNLP app started to work.
Please, be aware that this approach could cause security issues and use it only if you have no other option and 100% know what you are doing.