Question:
What can I do to help when I see a crash or hang in CrossCore Embedded Studio (CCES)?
=============================
Answer:
In the unlikely event you see a crash or hang, you first need to identify which of the two events occurred. A crash occurs when the CCES window disappears unexpectedly. A hang occurs when the CCES user interface freezes and stops responding to the mouse or keyboard.
When reporting such an issue in CCES to Support, it is of great benefit to the support team and the developers if you can provide log files, as detailed below.
Crash
If it was a crash, please e-mail processor.tools.support@analog.com, attaching the fatal error log that was generated by the Java Virtual Machine. This log file contains a stack trace that may help us debug the problem.
The fatal error log is a file named hs_err_pid<pid>.log where <pid> is the process id of the process. Normally this file is created in the working directory of CCES but sometimes it is created in the temporary directory specified by the TMP or TEMP environment variable.
You can usually find the fatal error log in the CCES\Eclipse directory, in the same directory as the .dxe that you were debugging, or in the temporary directory. If you can't find it in any of those locations, you could search likely directories, such as your workspace and your User directory (e.g. C:\Users\username). If you still can't find it, you could search your entire computer for hs_err_pid*.log and look for the most recent one.
Here is a sample of what the fatal error log looks like:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x06da805c, pid=4504, tid=2420
#
# JRE version: 6.0_24-b07
# Java VM: Java HotSpot(TM) Client VM (17.0-b17 mixed mode, sharing windows-x86 )
# Problematic frame:
# C [tpsdkserver.dll+0x3805c]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x02c0a400): VMThread [stack: 0x02cf0000,0x02df0000] [id=2420]
siginfo: ExceptionCode=0xc0000005, reading address 0x00000064
Registers:
EAX=0x00000000, EBX=0x00000000, ECX=0x00000000, EDX=0x02defb14
ESP=0x02defaf4, EBP=0x02defb2c, ESI=0x02c0a518, EDI=0x056d6e18
EIP=0x06da805c, EFLAGS=0x00010206
Top of Stack: (sp=0x02defaf4)
0x02defaf4: 01614d92 06dd647c 06e2c698 00000000
0x02defb04: 00000000 00000000 01017575 077b9e0c
0x02defb14: 02c0a518 00000020 02defb60 06dce9d0
0x02defb24: 00000000 02defb6c 02defb6c 06d82049
0x02defb34: 00000000 0756d5b8 66dd73a1 077be750
0x02defb44: 00000002 00000016 0756d5b8 66dd7e1b
0x02defb54: 51eb1e5c 0756d5b8 0756d5b8 02defbb0
0x02defb64: 66df8ca8 00000000 02defb78 66dd7e5b
Instructions: (pc=0x06da805c)
0x06da804c: c2 04 00 8b 7f 0c 3b fb 0f 84 81 00 00 00 8b 0e
0x06da805c: 8b 51 64 57 56 ff d2 8b d8 85 db 74 72 8b 06 8b
Stack: [0x02cf0000,0x02df0000], sp=0x02defaf4, free space=3fe02def668k
default frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=default code)
C [tpsdkserver.dll+0x3805c]
C [tpsdkserver.dll+0x12049]
C [Symman.dll+0x27e5b]
C [Symman.dll+0x264a6]
C [Symman.dll+0x3e9e3]
C [Symman.dll+0x3f60c]
C [Symman.dll+0x46e74]
C [Symman.dll+0x46ef1]
C [ntdll.dll+0x118a]
C [ntdll.dll+0x23aba]
C [kernel32.dll+0x1ca96]
C [kernel32.dll+0x1cb0e]
C [MSVCR71.dll+0x8d04]
C [MSVCR71.dll+0x8d11]
V [jvm.dll+0x20029d]
V [jvm.dll+0x1ff5ce]
V [jvm.dll+0x1ff8f0]
V [jvm.dll+0x1ffce2]
V [jvm.dll+0x185f5c]
C [MSVCR71.dll+0x9565]
C [kernel32.dll+0xb713]
Hang
If it was a hang, please e-mail processor.tools.support@analog.com, attaching the thread dump generated by Java VisualVM, which is available in the Java Development Kit(JDK) 6+. If you don't have JDK installed, we would be very appreciative if you can download it from here and install it, so that you can generate the thread dump.
To get a thread dump from Java VisualVM:
- add the following line to your CCES\Eclipse\cces.ini file:
-Dcom.sun.management.jmxremote
- run CCES and reproduce the hang
- run jvisualvm.exe which is located in your JDK's bin directory
- connect to CCES by double clicking on the CCES process under Applications->Local
- click on the Threads tab (if you don't see a Threads tab, you'll have to go back to edit your cces.ini file and restart CCES)
- click on the Thread Dump button to view the thread dump in a new tab.
The thread dump is a log of all the threads, their current states, and their stack traces. Here is a sample of what it looks like:
Full thread dump Java HotSpot(TM) Client VM (20.2-b06 mixed mode):
"JMX server connection timeout 40" daemon prio=6 tid=0x29901400 nid=0xa4c in Object.wait() [0x2bc9f000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(default Method)
- waiting on <0x037a0070> (a [I)
at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(Unknown Source)
- locked <0x037a0070> (a [I)
at java.lang.Thread.run(Unknown Source)
Locked ownable synchronizers:
- None
"RMI Scheduler(0)" daemon prio=6 tid=0x27620c00 nid=0x374 waiting on condition [0x2bb9f000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(default Method)
- parking to wait for <0x037a0100> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(Unknown Source)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(Unknown Source)
at java.util.concurrent.DelayQueue.take(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Locked ownable synchronizers:
- None
"RMI TCP Connection(1)-10.64.175.57" daemon prio=6 tid=0x28017c00 nid=0x1794 runnable [0x2b99f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(default Method)
at java.net.SocketInputStream.read(Unknown Source)
at java.io.BufferedInputStream.fill(Unknown Source)
at java.io.BufferedInputStream.read(Unknown Source)
- locked <0x037a0638> (a java.io.BufferedInputStream)
at java.io.FilterInputStream.read(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport.handleMessages(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Locked ownable synchronizers:
- <0x037adb38> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
"RMI TCP Accept-0" daemon prio=6 tid=0x276ae400 nid=0x1538 runnable [0x2b89f000]
java.lang.Thread.State: RUNNABLE
at java.net.PlainSocketImpl.socketAccept(default Method)
at java.net.PlainSocketImpl.accept(Unknown Source)
- locked <0x037a0838> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(Unknown Source)
at java.net.ServerSocket.accept(Unknown Source)
at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(Unknown Source)
at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
...
Other Files to Include
It would also be useful if you could create a .zip file with the .metadata directory that's located in your workspace directory and attach it to your e-mail. The .metadata directory includes your workspace preferences, launch configuration settings, and a log of what commands were executed during your debug session.
If you have a project or dxe to reproduce the crash or hang, it would be helpful to include it in the e-mail as well.