Berhubung pertanyaan tentang error code JVM sering diulang-ulang, ada baiknya di tulis saja di blog, sehingga memudahkan proses pemberian referensi.
The following table lists errors that can occur in the Java virtual machine (JVM) on BlackBerry handhelds.
(http://www.blackberry.com/developers/javaknowledge/general/kpa0307163334.shtml)
| Error | Description |
| 101 | Internal JVM error. |
| 102 | Invalid code in file system. The .cod files in the handheld have been checked for modification and it has been determined that there is a problem with one or more .cod files. |
| 103 | The starting address for the boot .cod file cannot be found. This might mean that a boot .cod file has not been installed on the handheld, or that its format is invalid or corrupt. |
| 104 | An uncaught Java exception was thrown in the Java code and diagnosed by the JVM. Execution can be continued or the handheld can be attached to a debugger on a desktop through a serial or USB cable. The event log should contain the traceback of the thrown exception. |
| 105 | An OS file system API returned an error status for a certain operation. This can indicate a corrupt file system or an error in the JVM. |
| 106 | An error has been detected in the graphics system of the handheld. |
| 107 | Internal JVM error. |
| 108 | Internal JVM error. |
| 109 | Internal OS error. |
| 110 | Non-idle event downtime error. A problem has been detected in the accumulation of JVM down time that represents how long the JVM has been idle. This indicates an error in either the OS code or the JVM code. |
| 200 | Application manager threw an uncaught exception. The application manager event thread threw an uncaught exception and so cannot continue running. |
| 201 | Initialization of the cryptographic system failed and the handheld cannot continue to operate. |
| 202 | An attack on the key store has been detected, and the handheld cannot continue to operate. |
| 203 | The application manager console process, usually the Home screen ribbon, has failed, like due to an uncaught exception. |
| 501 | Internal error. |
| 502 | All processes exited. The last Java process has terminated, and there is nothing left to execute. |
| 503 | Internal error. |
| 504 | Internal error. |
| 505 | Internal error. |
| 506 | An uncaught Java exception was thrown in the initial VM Java thread thus killing the only live thread in the system. The event log contains the traceback for the exception. |
| 507 | A dependency on a .cod file could not be satisfied due to a missing .cod file. Load the missing .cod file onto the handheld. |
| 508 | Invalid object. A problem has been detected with a debugger command to the VM. |
| 516 | Error occurred during garbage collection, which might indicate a corrupted file system. |
| 510 | All threads are waiting on objects, which results in a deadlock. The system cannot recover from this state since no thread can release a lock. |
| 511 | A problem has occurred during debugging. |
| 515 | The reachable objects form a group that cannot be represented properly by the VM because there are too many objects or the total size of the objects is too large. |
| 516 | When committing a persistent object, the VM found that the persistent store id counter has reached its limit. The object was not committed. |
| 517 | An inconsistency has been detected in the VM persistent object store. |
| 518 | Internal error. |
| 519 | Internal error. |
| 520 | Internal error. |
| 521 | Indicates that Object.wait() has been executed by a thread that holds a lock on another object; occurs only in simulator if the JvmDebugWaits application switch. |
| 522 | A thread has acquired two locks on objects in an order that doesn't match the order that previous locks for the two types were acquired, which indicates a future potential deadlock situation; reported only in the simulator when the JvmDebugLocks application switch is set. |
| 523 | A critical Java process has died and the device cannot continue to operate normally. |
| 524 | An object has been marked as recovered by the Low Memory Manager but it was not freed during a garbage collection. This is only checked in the simulator under the control of the JvmDebugLMM application switch. |
| 525 | Bad persistent object. An auto-commit operation during a garbage collection has detected a non-persistent object reachable from the persistent store root. The type of the object has been output into the event log. |
| 526 | The class definition for java.lang.Object cannot be found. |
| 527 | The class definition for java.lang.String cannot be found. |
| 528 | The file system is corrupted. Data on the handheld is unrecoverable. |
| 529 | The file system is corrupted. An attempt is going to be made to recover data, but some data might be lost. |
| 530 | Internal JVM error. |
| 531 | Flash memory has been exhausted. |
| 532 | A JVM assertion has been violated. This error can occur only in the simulator, not on an actual handheld. |
Posts
