Name: krT82822 Date: 03/28/99
Certain combinations of options for -Xrunhprof produce failures on an
x86 Solaris 2.7 machine (with no patches installed). For example,
consider the following class. I wrote it as part of a set of
performance measuring classes for my local Java platform. Its purpose
is simply to cause lots of wait()/notify() pairs and context switches.
final class MyInteger {
int value;
MyInteger(int val) {
value = val;
}
}
public final class Context extends Thread {
private static long startTime;
private static MyInteger turn = new MyInteger(-1);
private final int threads;
private final int num;
private final int loops;
public static void main(String[] argv) throws InterruptedException {
int threads = Integer.parseInt(argv[0]);
int loops = Integer.parseInt(argv[1]);
for (int i = 0; i < threads; i++) {
new Context(threads, i, loops).start();
}
startTime = System.currentTimeMillis();
synchronized (turn) {
turn.value = 0;
turn.notify();
}
Thread.sleep(3600000L); // Sleep for one hour; should be enough!
}
Context(int threads, int num, int loops) {
this.threads = threads;
this.num = num;
this.loops = loops;
}
public void run() {
int next = (num + 1) % threads;
try {
for (int i = 0; i < loops; i++) {
synchronized (turn) {
while (turn.value != num)
turn.wait();
turn.value = next;
turn.notifyAll();
}
}
} catch (InterruptedException intEx) {
}
if (num == threads - 1) {
long endTime = System.currentTimeMillis();
long totalTime = endTime - startTime;
System.out.println("Total time (milliseconds): " + totalTime);
System.out.println("Milliseconds per thread per operation: " +
((double)totalTime / (threads * loops)));
System.exit(0);
}
}
}
Note the following runs with the profiler turned on:
% java -Xrunhprof:cpu=times,monitor=y Context 10 10000
Total time (milliseconds): 6838
Milliseconds per thread per operation: 0.06838
Dumping contended monitor usage ...SIGSEGV 11* segmentation violation
si_signo [11]: SIGSEGV 11* segmentation violation
si_errno [0]: Error 0
si_code [1]: SEGV_MAPERR [addr: 0xA]
stackpointer=dba58dfc
Segmentation Fault
% java -Xrunhprof:cpu=times,format=b,monitor=y Context 10 10000
HPROF ERROR: cpu=times|old%
Notice that there was no newline after that (seemingly erroneous) error
message. Running with just cpu=times or just monitor=y works as expected.
Also, running in gdb yields the following:
Program received signal SIGSEGV, Segmentation fault.
0xdffd9288 in dumpQueue ()
(gdb) bt
#0 0xdffd9288 in dumpQueue ()
#1 0xdba59be8 in ?? ()
#2 0xdffb5af9 in jvmpi_dump_monitor ()
#3 0xdffb5bf3 in jvmpi_dump_monitor_rmon_helper ()
#4 0xdffadbf7 in registeredEnumerate ()
#5 0xdffb5c8a in jvmpi_collect_monitor_info ()
#6 0xdffb5dd1 in jvmpi_monitor_dump ()
#7 0xdffb4185 in jvmpi_RequestEvent ()
#8 0xdfd76e03 in hprof_dump_monitors ()
#9 0xdfd736ec in hprof_dump_data ()
#10 0xdfd73830 in hprof_jvm_shut_down_event ()
#11 0xdfd738ca in hprof_notify_event ()
#12 0xdffb4262 in jvmpi_cleanup ()
#13 0xdff8e221 in PrepareToExit ()
#14 0xdff8e248 in Exit ()
#15 0xdffa2ad2 in JVM_Exit ()
#16 0xdfc4ee2b in Java_java_lang_Runtime_exitInternal ()
#17 0xdffb77b3 in args_done ()
#18 0xdff84806 in invokeJNINativeMethod ()
#19 0xdbbab205 in j86PROFNativeJNIShim ()
#20 0x83f8de9 in ?? ()
#21 0x83e7172 in ?? ()
#22 0xdbbaaeb1 in JITInvokeCompiledMethodReturn ()
#23 0xdffb16da in invokeCompiledMethod ()
#24 0xdffbe22e in ivqw_not_ijn6 ()
Cannot access memory at address 0x270f.
Version information:
% java -version
java version "1.2"
Classic VM (build JDK-1.2-V, green threads, sunwjit)
% java -fullversion
java full version "JDK-1.2-V"
(Review ID: 56167)
======================================================================
Name: mc57594 Date: 12/12/99
The Solaris/x86 JDK 1.2.2 gets a core dump when you use
hprof with cpu=old or cpu=times from the "java" command.
This happens with any Java program.
When you use the "java_g" command instead, both work.
Note also that the 1.1.x -prof option now equates to cpu=old
and thus also gets a core dump.
This may be related to bug #4224724 but my report shows quicker
failure, failure for both old and times, and shows that java_g
works.
Example (any Java program can be used in place of "hello"):
$ uname -a
SunOS king 5.6 Generic_105182-03 i86pc i386 i86pc
$ $j122b/bin/java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2-001, green threads, sunwjit)
$ # this will work
$ $j122b/bin/java_g -Xrunhprof:cpu=old hello
Hello, Java!
Dumping CPU usage in old prof format ... done.
$ # this will crash
$ $j122b/bin/java -Xrunhprof:cpu=old hello
Segmentation Fault(coredump)
$ # ... as will the 1.1.x option
$ $j122b/bin/java -prof hello
Segmentation Fault(coredump)
$ # this will work
$ $j122b/bin/java_g -Xrunhprof:cpu=times hello
Hello, Java!
Dumping CPU usage by timing methods ... done.
$ # this will crash
$ $j122b/bin/java -Xrunhprof:cpu=times hello
Segmentation Fault(coredump)
(Review ID: 98889)
======================================================================
- relates to
-
JDK-5032156 NEWHPROF: performance issue with -Xrunhprof:monitor=y (Context testcase)
-
- Resolved
-
-
JDK-4325536 HPROF: crash when monitor=y option is used
-
- Closed
-
-
JDK-4626658 HPROF: run with the options "cpu=samples,monitor=y" causes VM crash
-
- Closed
-
-
JDK-4259542 HPROF: -Xrunhprof:cpu=times,... doesn't work
-
- Closed
-