Sunday Oct 19, 2008

Windows crash dumps for Java Processes

Windows Crash Dump is memory dump of a process running on a Windows system. These dumps can be very useful for debugging Java process crashes. In this entry I discuss how to collect sane Crash Dumps for Java process crashes on Windows machines that can later be analyzed using Windbg or other 'Debugging Tools For Windows'.

I have a simple java class test which uses native library test.dll using JNI. test.dll implements a 'native' method where it accesses a null pointer and causes a crash. Complete source of this crashing program is here


Windows NT, 2000 and XP

Let's first run this program on a Windows NT/2000/XP machine:

D:\\demo>java test
#
# An unexpected error has been detected by Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x10011f68, pid=2020, tid=640
#
# Java VM: Java HotSpot(TM) Client VM (10.0-b19 mixed mode, sharing windows-x86)
# Problematic frame:
# C [test.dll+0x11f68]
#
# An error report file with more information is saved as:
# D:\\demo\\hs_err_pid2020.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

Running this program created an hs_err log file in the same folder. Error log file contains the following stack trace:

C [test.dll+0x1032]
j test.f()V+0
j test.main([Ljava/lang/String;)V+19
v ~StubRoutines::call_stub
V [jvm.dll+0x873ed]
V [jvm.dll+0xdfb96]
V [jvm.dll+0x872be]
V [jvm.dll+0x8e501]
C [java.exe+0x14c5]
C [java.exe+0x69cd]
C [kernel32.dll+0x16fd7]

Now, let's run it with -XX:+ShowMessageBoxOnError JVM option. I get the following message box:

Attaching Visual Studio or Windbg to this process or collecting a crash dump with Dr Watson and opening that crash dump with Windbg shows the following call trace:

ntdll!DbgBreakPoint
jvm!VMError::show_message_box+0x7f
jvm!VMError::report_and_die+0xe7
jvm!report_error+0x2d
jvm!topLevelExceptionFilter+0x54d
jvm!os::os_exception_wrapper+0x7d
msvcr71!except_handler3+0x61
jvm!JavaCalls::call+0x23
jvm!jni_invoke_static+0xb1
jvm!jni_CallStaticVoidMethod+0x86
java+0x209e
java+0x898f
kernel32!GetModuleFileNameA+0x1b4

This shows JVM's error handling frames and does not show that the crash happened in function test.f().

This is because, by default, the First Chance Exceptions are not sent to the System Debugger. And Debuggers receive only the Second Chance Exceptions. The exception in test.f() was a first Chance Exception that was hanlded by JVM. Please see details on First and Second chance exceptions: http://support.microsoft.com/kb/286350

So how can we collect crash dumps that contain the correct stack trace of the crash. Let's try 'adplus' to collect the crash dumps.

Start adplus in crash mode:
D:\\windbg>adplus -crash -pn java.exe

and then start your java process with -XX:+ShowMessageBoxOnError

By default, adplus creates mini dumps on First Chance Exceptions and full memory dumps on Second Chance Exceptions. It can be changed; details here: http://support.microsoft.com/kb/286350

'adplus' would create dump files in a folder like Crash_Mode__Date_08-12-2008__Time_15-12-56PM. Using Windbg, open the dump created at First Chance Exception and it shows the crashing frame as:

test!Java_test_f+0x22

Ah! that's what I was looking for.



Windows 2008 and Windows Vista

Dr. Watson is not available on Windows 2008 and Windows Vista

Starting with Windows Server 2008 and Windows Vista Service Pack1 (SP1), Windows has new error reporting mechanism called 'Windows Error Reporting' or WER. WER can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. This feature is not enabled by default. Enabling this feature requires administrator privileges. To enable and configure the feature, we need to use the following registry values under the
HKEY_LOCAL_MACHINE\\Software\\Microsoft\\Windows\\Windows Error Reporting\\LocalDumps key.

Details here:

http://msdn.microsoft.com/en-us/library/bb787181(VS.85).aspx

And yes, here also we can use 'adplus' to collect Crash Dumps for First Chance and Second Chance Exceptions.



Enjoy Debugging !

Sunday Mar 09, 2008

How to create VC++ project for HotSpot workspace

I am sure very few people would know that on Windows platform, we can create a VC++ project for the HotSpot workspace in JDK sources. It is very useful as it gives me the ability to view and browse HotSpot source code and also build it at a simple click from Visual Studio IDE. It is also very helpful in debugging hotspot issues which can be reproduced on Windows with a simple testcase(and not just at customer site :) )

So let's see how we can create this project for OpenJDK hotspot workspace on 32bit platform and open it in Visual Studio.

There is a batch file 'create.bat' in \\build\\windows\\ folder which creates the VC++ project for hotspot workspace on Windows. Before we run this batch, we need to set two environment variables.

- The 32-bit OpenJDK Windows build requires Microsoft Visual Studio .NET 2003 (VS2003) Professional Edition compiler. Once the compiler is installed, we need to run VCVARS32.BAT to set the compiler environment variables

e.g.
D:\\openjdk7\\openjdk\\hotspot\\build\\windows>d:\\Progra~1\\Micros~1.NET\\Common7\\Tools\\vsvars32.bat
Setting environment for using Microsoft Visual Studio .NET 2003 tools.
(If you have another version of Visual Studio or Visual C++ installed and wish
to use its tools from the command line, run vcvars32.bat for that version.)

- Set the Path to include installed jdk bin folder (jdk6 or jdk7)
e.g.
set PATH=D:\\Java\\jdk1.6.0_03\\bin;%PATH%

Now, run create.bat

---------------------
D:\\openjdk7\\openjdk\\hotspot\\build\\windows>create.bat
Usage: create HotSpotWorkSpace HotSpotBuildSpace HotSpotJDKDist

This is the interactive build setup script (as opposed to the batch
build execution script). It creates HotSpotBuildSpace if necessary,
copies the appropriate files out of HotSpotWorkSpace into it, and
builds and runs MakeDeps in it. This has the side-effect of creating
the file in the build space, which is then used in Visual C++.
The HotSpotJDKDist defines place where JVM binaries should be placed.
Environment variable FORCE_MSC_VER allows to override MSVC version autodetection.

The generated project file depends upon the include databases. If
those are changed then MakeDeps is rerun.

NOTE that it is now NOT safe to modify any of the files in the build
space, since they may be overwritten whenever this script is run or
nmake is run in that directory.
-----------------------

Passing those required arguments:

D:\\openjdk7\\openjdk\\hotspot\\build\\windows>create.bat D:\\openjdk7\\openjdk\\hotspot d:\\hotspot\\build d:\\hotspot\\bin
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
Will generate VC7 project
vm.vcproj
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
NOTE: Using the following settings:
HotSpotWorkSpace=D:\\openjdk7\\openjdk\\hotspot
HotSpotBuildSpace=d:\\hotspot\\build
HotSpotJDKDist=d:\\hotspot\\bin
javac -g -d d:\\hotspot\\build\\jvmtifiles D:\\openjdk7\\openjdk\\hotspot/src/share/vm/prims/jvmtiGen.java
Generating d:\\hotspot\\build\\jvmtifiles/jvmtiEnv.hpp
Generating d:\\hotspot\\build\\jvmtifiles/jvmtiEnter.cpp
.....
..... cut the output here ....
.....
creating c1_ValueType.cpp
writing grand include file

writing dependencies file

.....................................................
Writing .vcproj file...
Done.
rm -f ad_x86_32.cpp ad_x86_32.hpp ad_x86_32_clone.cpp ad_x86_32_expand.cpp ad_x86_
d_x86_32_peephole.cpp ad_x86_32_pipeline.cpp adGlobals_x86_32.hpp dfa_x86_32.cpp
adlc -q -T -U_LP64 x86_32.ad
\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

This creates vm.vcproj file in d:\\hotspot\\build folder.

Open this in Visual Studio .Net and have fun!

Friday Nov 30, 2007

Building OpenJDK on Windows with NetBeans

Trying to build OpenJDK on Windows ? Here are some simple steps that may help...

Here are the softwares required for the build.

- Download OpenJDK from http://download.java.net/openjdk/jdk7/ and unzip the contents
- Download and install jdk 6.0 from http://java.sun.com/javase/downloads/index.jsp and jdk 7.0 from http://download.java.net/jdk7/binaries
- Download and install openjdk binary plugs from http://download.java.net/openjdk/jdk7/
- Install Microsoft Visual Studio .NET 2003 Professional
- Install Cygwin from http://www.cygwin.com. Make sure you install it in dos/text mode. Along with the default installation, we need to install Devel, Interpreters and Utils pakages. For the build, we need make 3.80, so if the cygwin make in not 3.80, download make bundle from http://cygwin.paracoda.com/release/make/make-3.80-1.tar.bz2 and untar it in a separate folder.
- Download and install findbugs from http://findbugs.sourceforge.net/downloads.html.
- Download and install Ant from http://ant.apache.org/bindownload.cgi
- Install Microsoft DirectX 9.0 SDK
- Download and install Microsoft Unicode library
- Install Freetype 2.3.4 from http://sourceforge.net/project/showfiles.php?group_id=3157
- Install NetBeans 6.0 from http://www.netbeans.org/downloads/

To build OpenJDK with NetBeans, open 'jdk' project in openjdk/jdk/make/netbeans/ with NetBeans. But first open a command window (cmd.exe) and set the path for following installed softwares:

set PATH=d:/utilities/usr/bin;d:\\devtools\\cygwin\\bin;D:\\devtools\\findbugs-1.3.0\\bin;
D:\\devtools\\apache-ant-1.7.0\\bin;%PATH%

Here, d:/utilities/usr/bin contains make 3.80. Also, it is setting the path for cygwin, FindBugs and ant.

then run vsvars32.bat of Microsoft Visual Studio .NET:
d:\\Progra~1\\Micros~1.NET\\Common7\\Tools\\vsvars32.bat

Now launch Netbeans from this command window.

In Netbeans, click on File->Open Project. Browse to openjdk/jdk/make/netbeans/ and select 'jdk'.

In openjdk/jdk/make/netbeans/common/make.xml file, change the location of bin/make to your 3.80 make.

<target name="-pre-init.windows" if="os.windows">
<property name="platform" value="windows"/>
<property name="make" value="d:/utilities/usr/bin/make"/>
</target>

In build.properties file, set the following environment variables:

bootstrap.jdk=d:/devtools/jdk1.7.0

make.options=\\
ALT_BOOTDIR=D:/Java/jdk1.6.0_03 \\
ALT_BINARY_PLUGS_PATH=D:/devtools/openjdk-binary-plugs \\
ALT_JDK_IMPORT_PATH=d:/devtools/jdk1.7.0 \\
ALT_DXSDK_PATH=d:/devtools/dxsdk9 \\
ALT_COMPILER_PATH=D:/Progra~1/Micros~1.NET/Vc7/bin \\
ALT_MSDEVTOOLS_PATH= D:/Progra~1/Micros~1.NET/Common7/Tools/Bin \\
ALT_MSVCR71_DLL_PATH= D:/Progra~1/Micros~1.NET/SDK/v1.1/Bin \\
ALT_FREETYPE_LIB_PATH=d:/devtools/freetype-2.3.4/lib \\
ALT_FREETYPE_HEADERS_PATH=d:/devtools/freetype-2.3.4/include \\
ALT_UNICOWS_LIB_PATH=d:/devtools/unicows \\
ALT_UNICOWS_DLL_PATH=d:/devtools/unicows \\
LD_LIBRARY_PATH= \\
CLASSPATH= \\
JAVA_HOME= \\
SHLVL=1 \\
OPENJDK=true

And that's all we need to do. Start the build (press F11 or right click on jdk project and click Build)

About

poonam

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today