The following table lists errors that can occur in
the Java virtual machine (JVM) on BlackBerry devices. Contact Research
In Motion® (RIM®) if you encounter any error codes not listed in
this table.
| Value |
Error |
Description |
| 101 |
Previous startup failed |
The device was reset during the JVM boot process. The
JVM found the boot in progress flag was set on startup.
The screen is intended to break continuous reset loops so that corrective
action can be taken. |
| 102 |
Invalid code in filesystem |
The system checked the COD files in the
device for modification and determined that a problem exists with
one or more COD files. If all loads fail, a build process
error might occur (a problem exists with signing the COD files). If
a user action on the device resulted in this problem, the reset
cycle is continuous because the code in the filesystem has been
corrupted. The only recovery method is to wipe the device and restore
a new system. |
| 103 |
Cannot find starting address |
The starting address for the boot COD file
cannot be found. This might indicate that a boot COD file has not
been installed on the device or that its format is invalid or corrupt. |
| 104 |
Uncaught: <Java-type-name> |
An uncaught Java exception was thrown by the Java
code and diagnosed by the JVM. Execution can continue, or the device
can be attached to a debugger on a desktop computer. The Microsoft® Windows®
Event Viewer log should contain the traceback of the thrown exception. |
| 105 |
Example, DbRecSize( %d ) -> %d |
The file system application programming interface (API)
has returned an error status for a specific operation. This might
indicate a corrupt filesystem or an error in the JVM. |
| 106 |
Graphics system error |
An error was detected in the graphics system
on the device. |
| 107 |
operator new() called |
A C++ class in the JVM was coded incorrectly
to inherit from VMRamObject that has the correct override for operator
new. Extract the current (post-reset) BUGDISP. |
| 108 |
operator delete() called |
A C++ class in the JVM has was coded incorrectly to
inherit from VMRamObject that has the correct override for operator
delete. Extract the current (post-reset) BUGDISP. |
| 109 |
PriorityMessageCount error: <priority-count> |
The value returned by RimPriorityMessageCount
is negative. It should always be greater than, or equal to, zero.
This indicates an error in the operating system code. Extract the
current (post-reset) BUGDISP and EVENTLOG. |
| 110 |
Non-idle event downtime error: <down-time>
<idle-down-time> |
A problem was detected in the accumulation
of JVM down time, which represents how long the JVM has been idle.
This usually indicates an error in the device firmware or the JVM.
This could also occur if the tick count rolls over after 400 or
more days of device time. |
| 111 |
Font engine error |
An error was detected in the font engine system
on the device. Extract the current (post-reset) BUGDISP and EVENTLOG. |
| 112 |
Java Native Assertion Failure |
An error was detected in the Java native code. Extract
the current (post-reset) BUGDISP and EVENTLOG. |
| 200 |
Application manager threw an uncaught exception |
The application manager event thread threw
an uncaught exception and cannot continue execution. |
| 201 |
Crypto initialization code failed |
The initialization of the crypto system failed
and the device cannot continue execution. |
| 202 |
An attack on the key store has been detected |
An attack has been detected and execution cannot continue. |
| 203 |
Console process died |
The application manager console process (usually the
Ribbon) has died. This is likely due to an uncaught exception during
execution. |
| 204 |
Persistent Content Exception |
An application tried to commit a plaintext
object to the Persistent Store. This will only happen if Content Protection
is on and a process tries to save something in the PersistentStore
that is marked as plaintext. Since this exception was not handled,
the persistent store is in a bad state. You should reset to roll
back to the last good commit point. Note: This is not a JVM erro;
the JVM is simply diagnosing the problem. The eventlog contains information
about the erroneous Java code. |
| 501 |
VM_THREAD_SWITCHED: Internal Error |
This is an error return used internally in
the VM. It should never be reported as a device error. |
| 502 |
VM_PROCESS_DEATH: All processes exited |
The last Java process has terminated. There
is nothing left to execute. |
| 503 |
VM_THREAD_DEATH: Internal Error |
This is an error return used internally in
the VM. It should never be reported as a device error. |
| 504 |
VM_THREAD_SWITCH: Internal Error |
This is an error return used internally in
the VM. It should never be reported as a device error. |
| 505 |
VM_BAD_CODE: Bad Byte Code |
An error has occurred in the JIT compiler. |
| 506 |
Uncaught Exception |
An uncaught Java exception was thrown in the
initial VM Java thread, thus ending the only live thread in the
system. The eventlog contains the traceback for the exception. |
| 507 |
Unsatisfied Link |
A dependency on a COD file could not be satisfied because
the COD file is missing. |
| 508 |
Invalid object |
A problem has been detected with a debugger command
to the VM. |
| 509 |
VM_PPO_INFINITE_LOOP: infinite loop in PPO
phase of GC |
The maximum iteration count for the PPO phase
of a GC must be the maximum number of file handles in the system.
This error indicates that the iteration count exceeds the maximum.
Hence, a flaw exists in the PPO loop or a corrupted file system.
The extra hex integer in the error string is the flash id of the current
record where the infinite loop was detected. |
| 510 |
Deadlock |
All threads are waiting on objects, resulting
in deadlock. The system cannot recover from this state because no
thread can release a lock. |
| 511 |
Debug connection died |
A problem has occurred while debugging that
may be caused by a VM problem or an incorrect debugging command
being sent to the VM. |
| 512 |
GC Aborted |
An idle garbage collection has been interrupted
by a user event (for instance, a key was pressed or the trackwheel
was used). |
| 513 |
<clinit> needs running |
An opcode requires that a class <clinit>
execute before it can continue execution. |
| 514 |
<init> needs running |
A new instance of a class has been allocated
and it must be initialized by the default constructor before it
can be used. |
| 515 |
Object group too big |
The reachable objects form a group that cannot
be represented properly by the JVM because either there are too
many objects or the total size of the objects is too large. |
| 516 |
Persistent ids exhausted |
When committing a persistent object, the JVM
found that the persistent store id counter reached its limit. The
object was not committed and a critical error was reported. This
error should not occur unless a device is heavily used for years. |
| 517 |
Filesystem corrupt |
An inconsistency was detected in the JVM persistent
object store. |
| 518 |
Unexpected longjmp |
A garbage collection marking phase was terminated via
a longjmp. This indicates that the marking phase was interrupted
when it should have completed without interruption. This error should
not occur because these actions are executed when the device is
not idle, and GCs can only be interrupted when the device is idle. |
| 519 |
Internal Error |
The JVM host is missing or has been disabled. |
| 520 |
Internal Return |
This is an internal state that indicates a
Java method return needs to be executed. |
| 521 |
Dangerous Wait |
An Object.wait() was executed by a thread that holds
a lock on another object. |
| 522 |
Interlaced synchronization |
A thread acquired two locks on objects in an
order that doesn't match the order in which a lock on the two types
were previously acquired. This indicates a future potential deadlock
situation and is reported. The check is only available in the simulator
under the control of the JvmDebugLocks application switch. |
| 523 |
System process died |
A critical Java process has terminated, and
the device cannot continue to operate in a normal manner. |
| 524 |
LMM error |
An object has been marked as recovered by the Low
Memory Manager, but it was not freed during a garbage collection. |
| 525 |
Bad persistent object |
An auto-commit operation during a garbage collection
detected a non-persistent object reachable from the persistent store
root. The type of the object was output into the eventlog. |
| 526 |
java.lang.Object not found |
The class definition for java.lang.Object cannot
be found. |
| 527 |
java.lang.String not found |
The class definition for java.lang.String cannot
be found. |
| 528 |
Corrupt filesystem. Unrecoverable. All data
will be lost |
All data will be lost when execution continues.
The error message screen contains a number representing an internal
reason for the corruption. This error is not diagnosed if a COD
file was removed because the JVM must delete objects that were defined
in the removed COD file. Thus, this error is not expected in normal
device operation. Refer to the following reason codes:
- Root array reference is not a valid array reference
- Root array type is not Object[]
- Root array size < 1 (i.e., Object[0])
- Contents of root[0] is not a valid ref
- Type of root[0] is not a LongIntHashtable
- Persistent segmented array header contains an invalid
reference
- An entry in a persistent Object[] contains an invalid
reference
- An Object's type refers to an unknown codfile
- An Object's type description in the codfile doesn't match
the size in the store
- A reference type field in an Object has an invalid reference
in it
- A reference type field in an object points to an object
of the wrong type
- A persistent Object[] is missing its descriptor
- Object in persistent store is not marked as persistable
- Root array is segmented and one of the segments is invalid
|
| 529 |
Corrupt filesystem. About to attempt recovery.
Some data may be lost |
Some data will be lost when execution continues. The
error message screen contains a number representing an internal
reason for the corruption. This error is not diagnosed if a COD
file WAS removed because the VM must delete objects that were defined
in the removed COD file. Thus, this error is not expected in normal
device operation. Refer to the following reason codes:
- Root array reference is not a valid array reference
- Root array type is not Object[]
- Root array size < 1 (i.e., Object[0])
- Contents of root[0] is not a valid ref
- Type of root[0] is not a LongIntHashtable
- Persistent segmented array header contains an invalid
reference
- An entry in a persistent Object[] contains an invalid
reference
- An Object's type refers to an unknown codfile
- An Object's type description in the codfile doesn't match
the size in the store
- A reference type field in an Object has an invalid reference
in it
- A reference type field in an object points to an object
of the wrong type
- A persistent Object[] is missing its descriptor
- Object in persistent store is not marked as persistable
- Root array is segmented and one of the segments is invalid
|
| 530 |
VM_PREVENT_GC_OVERFLOW: _preventGC overflow |
A fixed number of native objects can be protected from
garbage collection. This error indicates that a native has exceeded
the fixed limit of objects that can be protected. If the device
is reset or thread tracebacks are logged, the name of the actual native
can be extracted. |
| 531 |
Flash exhausted |
There are certain operations where the JVM
cannot withstand running out of flash space. In these circumstances,
this error will be reported if the JVM cannot allocate a required
amount of flash space. |
| 532 |
VM_ASSERTION_FAILED: Assertion failed |
Normally this JVM error should not be reported since
the device is not shipped with assertions enabled. The simulator
may report this error in debug mode indicating a VM assertion was
violated. Try typing BKPT to activate the debugger
and dump the native call stack for forwarding to the VM team. |
| 533 |
VM_RUN_METHOD: <method> needs running |
This is used internally for ECMAScript to call
Java methods. |
| 534 |
VM_FAST_RESET_DISABLED: Fast Reset Disabled |
This is used internally to indicate that fast
reset capability is not available. Often used in platform-specific
code. |
| 535 |
VM_UNUSED_535: Unused |
This is an unused VM error. |
| 536 |
VM_FAST_RESET_BAD_INSTANCE: VM Instance Check
Failed |
This is used internally to indicate that the
VM structure passed in is at the wrong address or has been corrupted. |
| 537 |
VM_FAST_RESET_BAD_HEAP: Heap Check Failed |
This is used internally to indicate that the
VM heap has been corrupted or pointers into the heap have been corrupted. |
| 538 |
VM_FAST_RESET_BAD_IRAM: IRAM Check Failed |
This is used internally to indicate that the
VM IRAM checks have detected corruption of VM data structures (threads
and local stacks) that reside in IRAM. |
| 539 |
VM_FAST_RESET_NOT_IDLE: Not Idle |
This is used internally to indicate that the
VM was not idle when the reset occurred and, as such, cannot continue
with a fast reset. |
| 540 |
VM_FAST_RESET_MULTIPLE_RESETS: Multiple Resets |
This is used internally to indicate that the
time since the last fast reset is less than a minimum time. By disallowing
multiple fast resets in a short amount of time, this should prevent
fast reset loops. |
| 541 |
VM_HEAP_COMPACT_INFINITE_LOOP: infinite loop
detected in heap compaction |
The VM detected a problem in its RAM heap that indicates
its RAM was corrupted. The problem was detected by identifying a
possible infinite loop during RAM heap compaction. A bugdisp log
and eventlog should be extracted quickly when the device is in this
condition. If possible, images of RAM should be saved. |
| 542 |
Transient memory leak |
The JVM detected that some memory was not freed,
indicating that a memory leak has occurred. This condition is detected
as early as possible to improve chances of isolating the cause. |
| 543 |
VM_FS_MISMATCH: Incompatible Java filesystem
installed |
The VM detected that the operating system binary
is different from the operating system binary used to create the
Java file system. This means that the Java native methods may not
be linked properly and as such, the integrity of the system cannot
be guaranteed. The system can be recovered by using the VM DLFX
and DLPS commands to delete the fixups and persistent store. This
will clear all data and fixups and let the filesystem re-link to
match the new operating system binary. Note: The recovery order
is: - Delete fixups
- Delete persistent store
- Reset device
|
| 544 |
VM_SECTION_MAP_OVERFLOW: a module references more
than 255 other modules |
The VM detected that a module is trying to reference
more than 255 other modules. Extract the filesystem immediately
when this error is detected. |
| 545 |
VM_INCOMPATIBLE_FILESYS: an incompatible or corrupt
filesystem was found |
The VM detected an incompatible or corrupt filesystem.
Extract the filesystem immediately when this error is detected. |
| 546 |
VM_UNUSED_546: unused |
The VM detected that the RAM image of its filesystem
is corrupted (failed CRC check). Better to reset than to duplicate
the corruption into flash. |
| 547 |
VM_UNUSED_547: unused |
This is an unused VM error. |
| 548 |
VM_UNUSED_548: unused |
This is an unused VM error. |
| 549 |
VM_UNUSED_549: unused |
This is an unused VM error. |