-
Bug
-
Resolution: Fixed
-
P3
-
6
-
b28
-
generic
-
solaris
-
Not verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8056374 | emb-9 | Zhengyu Gu | P3 | Resolved | Fixed | b28 |
JDK-8248714 | 8u271 | David Buck | P3 | Resolved | Fixed | b01 |
JDK-8251608 | emb-8u271 | David Buck | P3 | Resolved | Fixed | team |
I was imitating "failed strdup" by returning NULL and setting "errno = ENOMEM".
Injecting such faults in JVM results in multiple JVM crashes
(both in product and debug releases).
In particular 'java -version' crashes in case faults were injected on:
10-15
28-37
66-72
strdup invocations.
For example if strdup failure happens on 11th invocation of strdup JVM
crashes with error:
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xff230bf0, pid=11693, tid=2
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-fastdebug-b83-debug mixed mode, sharing)
# Problematic frame:
# [error occurred during error reporting, step 60, id 0xb]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Looking at stack trace:
=>[1] strdup(0x32bd0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff380654
[2] LazyClassPathEntry::LazyClassPathEntry(0x32c38, 0xfede5cc0, 0xfe77fb00, 0x9c00, 0x3c4e54, 0xfeddc000), at 0x
[3] ClassLoader::setup_bootstrap_search_path(0x32c38, 0x275, 0xfedef3a0, 0xfe77fb04, 0x32bd0, 0xfeddc000), at 0x
[4] ClassLoader::initialize(0x9c00, 0xfe77fcfc, 0xfeddc000, 0x0, 0xfede5c68, 0x30400), at 0xfe8543ec
[5] init_globals(0x16800, 0x1685c, 0x0, 0xfeddc000, 0x58c97c, 0xfed72088), at 0xfe84f6b0
[6] Threads::create_vm(0x16c00, 0xfe77ff1b, 0x30400, 0x16bfc, 0xff342400, 0xfeddc000), at 0xfec7fcb4
[7] JNI_CreateJavaVM(0xfe77ff94, 0xfe77ff90, 0xfe77ff80, 0xfedf0234, 0xfe846974, 0xfeddc000), at 0xfe84672c
[8] JavaMain(0xfe84665c, 0x2b1a4, 0x0, 0x0, 0x0, 0x1), at 0x12648
looks like LazyClassPathEntry::LazyClassPathEntry doesn't check strdup
return value for NULL:
193: LazyClassPathEntry::LazyClassPathEntry(char* path, struct stat st) :
194: ClassPathEntry() {
195: _path = strdup(path);
196: _st = st;
197: _meta_index = NULL;
198: _resolved_entry = NULL;
199: }
The same situation probably exists for other failures.
To reproduce the failure:
1. login on solaris machine
2. cp -fr /home/ep155969/work/FaultInjection/strdup YOUR_LOCAL_DIR
3. cd YOUR_LOCAL_DIR
4. make
5. export LD_PRELOAD=./mystrdup.so
6. export INJECT_FAULT_AT=11
7. JAVA_PATH -version
To see stack trace for particular failure do:
1-6
7. export WAIT_AFTER_INJECTION=1
8. JAVA_PATH -version & JAVA_PID=$!
9. login to another terminal or set LD_PRELOAD=
10. dbx JAVA_PATH $JAVA_PID
You can also inject failures in all places strdup is called at and see when JVM
does crash. To do it run inject_strdup_faults.sh:
bash inject_strdup_faults.sh JAVA_PATH INJECTION_START INJECTION_END
The failure results will be stored in ./results dir.
Example:
bash inject_strdup_faults.sh /net/koori.sfbay/onestop/jdk/1.6.0/latest/binaries/solaris-i586/bin/java 1 80
To see how many times strdup is called set INJECT_FAULT_AT=0 and run
"JAVA_PATH -version".
Injecting such faults in JVM results in multiple JVM crashes
(both in product and debug releases).
In particular 'java -version' crashes in case faults were injected on:
10-15
28-37
66-72
strdup invocations.
For example if strdup failure happens on 11th invocation of strdup JVM
crashes with error:
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xff230bf0, pid=11693, tid=2
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-beta2-fastdebug-b83-debug mixed mode, sharing)
# Problematic frame:
# [error occurred during error reporting, step 60, id 0xb]
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#
Looking at stack trace:
=>[1] strdup(0x32bd0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xff380654
[2] LazyClassPathEntry::LazyClassPathEntry(0x32c38, 0xfede5cc0, 0xfe77fb00, 0x9c00, 0x3c4e54, 0xfeddc000), at 0x
[3] ClassLoader::setup_bootstrap_search_path(0x32c38, 0x275, 0xfedef3a0, 0xfe77fb04, 0x32bd0, 0xfeddc000), at 0x
[4] ClassLoader::initialize(0x9c00, 0xfe77fcfc, 0xfeddc000, 0x0, 0xfede5c68, 0x30400), at 0xfe8543ec
[5] init_globals(0x16800, 0x1685c, 0x0, 0xfeddc000, 0x58c97c, 0xfed72088), at 0xfe84f6b0
[6] Threads::create_vm(0x16c00, 0xfe77ff1b, 0x30400, 0x16bfc, 0xff342400, 0xfeddc000), at 0xfec7fcb4
[7] JNI_CreateJavaVM(0xfe77ff94, 0xfe77ff90, 0xfe77ff80, 0xfedf0234, 0xfe846974, 0xfeddc000), at 0xfe84672c
[8] JavaMain(0xfe84665c, 0x2b1a4, 0x0, 0x0, 0x0, 0x1), at 0x12648
looks like LazyClassPathEntry::LazyClassPathEntry doesn't check strdup
return value for NULL:
193: LazyClassPathEntry::LazyClassPathEntry(char* path, struct stat st) :
194: ClassPathEntry() {
195: _path = strdup(path);
196: _st = st;
197: _meta_index = NULL;
198: _resolved_entry = NULL;
199: }
The same situation probably exists for other failures.
To reproduce the failure:
1. login on solaris machine
2. cp -fr /home/ep155969/work/FaultInjection/strdup YOUR_LOCAL_DIR
3. cd YOUR_LOCAL_DIR
4. make
5. export LD_PRELOAD=./mystrdup.so
6. export INJECT_FAULT_AT=11
7. JAVA_PATH -version
To see stack trace for particular failure do:
1-6
7. export WAIT_AFTER_INJECTION=1
8. JAVA_PATH -version & JAVA_PID=$!
9. login to another terminal or set LD_PRELOAD=
10. dbx JAVA_PATH $JAVA_PID
You can also inject failures in all places strdup is called at and see when JVM
does crash. To do it run inject_strdup_faults.sh:
bash inject_strdup_faults.sh JAVA_PATH INJECTION_START INJECTION_END
The failure results will be stored in ./results dir.
Example:
bash inject_strdup_faults.sh /net/koori.sfbay/onestop/jdk/1.6.0/latest/binaries/solaris-i586/bin/java 1 80
To see how many times strdup is called set INJECT_FAULT_AT=0 and run
"JAVA_PATH -version".
- backported by
-
JDK-8056374 JVM crashes on failed 'strdup' call.
- Resolved
-
JDK-8248714 JVM crashes on failed 'strdup' call.
- Resolved
-
JDK-8251608 JVM crashes on failed 'strdup' call.
- Resolved
- relates to
-
JDK-8054936 Back out fix for JDK-6424123
- Closed