(I'm not a Java programmer, just an end-user trying to deal with a lack of exception handling and reporting in someone else's code.)
Is there a way to get more detailed info such as variable names and values from Java when it back-traces an unhandled exception?
This is in regards to a Minecraft server log, apparently there's a corrupt chunk file somewhere. The error trace seems too vague to tell me exactly where the problem is located, such as the specific datafile name involved in the error.
2013-12-16 11:19:03 [WARNING] Failed to handle packet for PlayerName [/XX.XX.XX.XX:5046]: java.lang.ArrayIndexOutOfBoundsException: -448550
at java.util.ArrayList.elementData(ArrayList.java:371)
at java.util.ArrayList.set(ArrayList.java:399)
at net.minecraft.world.chunk.storage.RegionFile.<init>(RegionFile.java:89)
at net.minecraft.world.chunk.storage.RegionFileCache.func_76550_a(SourceFile:61)
at net.minecraft.world.chunk.storage.AnvilChunkLoader.chunkExists(AnvilChunkLoader.java:63)
at net.minecraft.world.gen.ChunkProviderServer.getChunkAt(ChunkProviderServer.java:167)
at net.minecraft.server.management.PlayerInstance.<init>(PlayerInstance.java:38)
at net.minecraft.server.management.PlayerManager.func_72690_a(PlayerManager.java:116)
at net.minecraft.server.management.PlayerManager.func_72683_a(PlayerManager.java:175)
at net.minecraft.server.management.ServerConfigurationManager.func_72375_a(ServerConfigurationManager.java:269)
at net.minecraft.server.management.ServerConfigurationManager.func_72377_c(ServerConfigurationManager.java:335)
at net.minecraft.server.management.ServerConfigurationManager.func_72355_a(ServerConfigurationManager.java:180)
at net.minecraft.network.NetLoginHandler.completeConnection(NetLoginHandler.java:218)
at cpw.mods.fml.common.network.FMLNetworkHandler.handleClientConnection(FMLNetworkHandler.java:171)
at cpw.mods.fml.common.network.FMLNetworkHandler.onConnectionReceivedFromClient(FMLNetworkHandler.java:124)
at net.minecraft.network.NetLoginHandler.func_72529_d(NetLoginHandler.java:194)
at net.minecraft.network.NetLoginHandler.func_72532_c(NetLoginHandler.java:81)
at net.minecraft.server.ServerListenThread.func_71766_a(ServerListenThread.java:57)
at net.minecraft.server.dedicated.DedicatedServerListenThread.func_71747_b(SourceFile:29)
at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:865)
at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:320)
at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:732)
at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:614)
at net.minecraft.server.ThreadMinecraftServer.run(SourceFile:573)
From the logs, I understand that a player is trying to log on, and it's loading the world data where the player was last located, but a region file is corrupt and an array in the file data is invalid.
But which region file? It doesn't tell me that.
Can these error logs be made to be more verbose with variable names and values, such as with an extra startup java command line setting?
I'm finding very little to explain how to even interpret these back traces. I assume the numbers at the end of each line are referring to line numbers within the source code, but I'm not able to edit the code so examining the source at those lines would not help anyway.
Environment: Ubuntu 13.10
java version "1.7.0_25"
OpenJDK Runtime Environment (IcedTea 2.3.12) (7u25-2.3.12-4ubuntu3)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
You really want to learn how to use a source-level debugger. These will let you step through the code, stopping at interesting points or when an exception is thrown, and examine (and often even modify) variable values.
Which is best is very much a matter of taste, but I'm going to break the rule here and suggest you try the Eclipse environment simply because it's the only IDE I've ever used which really does a good job of integrating code authoring, debugging, and management.
(The Java runtime environment does have its own debugger, which can do most of the same things -- but it's a commandline tool and I think it's significantly harder for a novice to learn. There are times when it's the right tool, mostly when you have to work remotely over a very limited connection, but I don't suggest you start with it.)
Related
A project I am currently involved in uses JavaCv/OpenCv for face detection. Since the OpenCv occasionally throws an error, and the propagation of OpenCv/C++ errors to Java Exceptions isn't fully functional yet, this means the Java main-loop crashes with no way to recover.
However, the code gives mostly accurate results, and since we're running it on a large database I baked a quick Batch-script around the execution to keep it going, and the Java code internally manages an id, to make sure it continues from just after where it crashed.
:RETRY
java -Xmx1024m -jar Main.jar
IF ERRORLEVEL 1 GOTO RETRY
EXIT 0
However, occasionally I get a Runtime Error pop-up, as follows:
Microsoft Visual C++ Runtime Library
Runtime Error!
Program: C:\Windows\System32\java.exe
This application has requested the runtime to end in an unusual way.
Please contact the application's support team for more information.
At which point the code execution halts until the pop-up is clicked, which is really annoying, as it means my code can't run without me babysitting it.
I found this question, which basically asks the same thing. There is an accepted solution for that question, but since I'm not directly working with C++, I don't see how I can implement this.
Is there a Batch-level solution to this problem? Is there a Java/JavaCv-level solution to catch the C++ errors coming from OpenCv? Any other solution?
Interesting question.
Java.exe is dependent on one or more of Visual C++ DLLs (like MSVCRT.DLL, msvcr90.dll etc). Probably the JAR file is causing Java.exe to cause this error. Java.exe must be calling some CRT function which is raising the exception and hence the Runtime Error.
The best bet you can do is to launch the process, let this error pop and then start Process Explorer, and see the call stack. Nevertheless, solving this issue is most probably out of your control. May be latest version of Java may help.
Since Java update 25 the VM crashes occasionally with internal error. With previous versions <25 it was working fine. According to the release notes, the hotspot compiler was modified in update 25. Does it produce defect code that causes the crash? It does not crash if the JIT compiler is turned off with -Xint. I filed a bug here http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054478 .
How do I interpret the log file to find out where the crash occurs. I am not able to identify the lines in my Java code where it happenes.
I searched the Bug Database for the string "Unexpected result from topLevelExceptionFilter", and there were three other hits. They all seem to be about unexpected exceptions in native code propagating back across the JNI boundary.
Is that clue relevant to your application?
The reason is that an internal assertion failed - the JVM was not in the state it expected to be. This is a good thing because it avoids propagating errors, but a bad thing because it doesn't tell you how to get around it.
If simple tricks like -client or -server doesn't help, then consider a different JVM.
IBM has a Windows JVM, but it is a bit tricky to get. The easiest for now would be a development package http://www.ibm.com/developerworks/java/jdk/eclipse/index.html
Oracle also have JRockit. http://www.oracle.com/technetwork/middleware/jrockit/index.html
This will allow you to work while Oracle has a look at your bug. It is low priority though, so it make take a while.
I've been attempting to execute a java application using SSH from a remote machine
but it quite doesn't work well :(
To execute this application on the local machine,
I wrote a shell script including java command, and it works okay on local.
So, I tried to execute this shell script remotely via ssh like below
ssh username#hostname execute.sh
It seemed to worked out at first, but then result in the following error, and shutdown.
GC Warning: Repeated allocation of very large block (appr. size 929792): May lead to memory leak and poor performance.
GC Warning: Out of Memory! Returning NIL!
I understood what the message means reading this page ( http://www.hpl.hp.com/personal/Hans_Boehm/gc/debugging.html ),
yet, I have no idea how come this error occur only when I execute java command remotely.
Does anyone know anything about this?
Or, is there any better way to execute java command remotely
other than ssh?
Any idea or information will be greatly appreciated!
Regards,
May
java version: Java(TM) SE Runtime Environment (build 1.6.0_18-b07)
The only difference between exec'ing a command locally vs remotely would be the environmental variable setup. Please check that environment variables your program might be using (such as JAVA_HOME) are being set to expected values
It worked out using "expect" command. Still I don't know the reason of the GC Warnings thou..
Thank you guys for all the comments.
The compilation was successful
The multiplication should have been performed at compile time without any code being generated.
However, your solution generated the following code:
Java HotSpot(TM) 64-Bit Server VM warning: Can't detect initial thread stack location - find_vma failed
mov ax,5
mov ax,6
mul ax
[ the expected value was 30, but you calculated the result as 6 ]
I entered some code in my school's system and I got this error message. I don't understand the part where it says "The multiplication should have been performed at compile time without any code being generated.".
Anyone know what I might be doing wrong?
(I can't reveal the code I entered in it, because I don't want it showing up in a search engine. Is there a way I can privately show the code I entered in?)
On my Ubuntu 10.04/64-bit system, java was unable to access the /proc filesystem.
Specifically, I was running in a chroot which didn't have it mounted:
mount -t proc none /proc
I encountered the same problem in my chroot environment. As #chronospoon suggested, it is because java was unable to access the /proc filesystem.
However, the correct mounting command is the following (note that both proc does not prefixed by /), as mentioned in here:
mount -t proc none proc
To check whether the mounting is successful, just check whether the proc directory has any file.
The message "Can't detect initial thread stack location" is quite common, see e.g., here and here. The remaining part is strange, the assembly code is pure nonsense. I wouldn't care about that, it isn't your fault.
The Can't detect initial thread stack location suggests an incomplete or corrupt Java installation.
The stuff about multiplication at compile time doesn't look like it comes from Java, but instead from some sort of IDE or compilation tool that your school is using. Whatever this "school system" is, you need to ask whoever is responsible for it about these error messages.
I suspect that this is an artifact of the "school system" that you are using, which appears to be some framework for automating code testing.
The message looks system specific to me.
If the message is no system specific, it is a (arguably) a bug for a production application to be reporting obscure HotSpot errors to end users.
So, I think you should be asking the people who manage the system, and (presumably) understand what that message means.
What is the best practice to solve a Java VM crash if the follow conditions are true:
No own or third party native code. 100% pure java
The same program run on many other system without any problems.
PS: With VM crash I means that the VM write a dump file like hs_err_pid1234.log and terminate.
Read the hs_err_pid1234.log file (or whatever the error log file name is). There are usually clues in there. The next step depends on what you discover in the log.
Yes, it could be a bug in the specific version of the JVM implementation you are using, but I have also seen problems caused by memory fragmentation in the operating system. Windows, for example, is prone to pin dlls at inappropriate locations, and fail to allocate a contiguous block of memory when the JVM asks for it as a result. Other out opf memory problems can also manifest themselves through crash dumps of this type.
Update or replace your JVM. If you currently have the newest version, then try an older one, or if you don't have the latest version, try updating to it. Maybe its a known issue in your particular version?
Assuming the JVM version across machines is the same:
Figure out what is different about the machine where the JVM is crashing. Same OS and OS version? We have problems with JVMs crashing on a particular version of Red Hat for example. And we have also found some older Red Hat versions unable to cope with extra memory properly, resulting in running out of swap space. (Our solution was to upgrade RedHat).
Also, is the program doing exactly the same thing across machines? Is it accessing a shared filesystem? Is the file system mounted similarly on your machines (SMB/NFS etc)? Something must be different.
The log file should give you some idea of where the crash occurred (malloc for example).
Take a look at the stacktraces in the dump file, as it should tell you what was going on when the crash occurred.
As well as digging into the hs_err dump file, I'd also submit it to Sun or whomever made your JVM (I believe there are instructions in how to do so at the top of the file?). It can't hurt.
32bit? 64bit? Amount of ram in client machine? processor? os? See if there is any connection between the systems. A connection may lead to a clue. If all else fails, consider using different major/minor versions of the JVM. Also, if the problem JUST started can you get to a time (via version control) where the program didn't crash? Look through the hs_err log, you may get an idea of what caused the crash. It could be a version of some other client library the JVM uses. Lastly, run the program in debug/profile and maybe you'll see some symptons before the crash (assuming you can duplicate it)