You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Chad Maniccia <CM...@mbgaustin.com> on 2014/10/03 18:07:18 UTC
Re: Tomcat JVM Crash
Hi,
I have discovered the source of the JVM crashes. I figured it best to share with the group because it is quite odd. I have tested this and confirmed with a colleague so as odd as it sounds it is reproducible.
The crash is caused by a combination of Chrome web browser, HTTPS, and posting a form with an exact amount of data. If you use HTTP to submit the form=no crash, If you use IE and HTTPS=no crash. If you add/remove a single character to the form=no crash. I have attached the latest crash log. Please note that Tomcat crashes before it logs the request to "localhost_access_log" and before it passes the request to the servlet. This problem is present between multiple versions of Java and Tomcat.
Here is another user reporting a similar issue.
https://bugs.openjdk.java.net/browse/JDK-8049855
I did like they suggested and added the following line. This doesn't fix the problem but it prevents the server from crashing, you get a blank page instead. Why is this?
-XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
Thanks,
Chad
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (sharedRuntime.cpp:833), pid=70000, tid=58036
# fatal error: exception happened outside interpreter, nmethods and vtable stubs at pc 0x00000000015a3eb0
#
# JRE version: Java(TM) SE Runtime Environment (8.0_20-b26) (build 1.8.0_20-b26)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.20-b23 mixed mode windows-amd64 compressed oops)
# Core dump written. Default location: C:\Program Files\Apache Software Foundation\Tomcat 8.0\hs_err_pid70000.mdmp
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
#
--------------- T H R E A D ---------------
Current thread (0x000000001f35a000): JavaThread "http-nio-443-exec-4" daemon [_thread_in_Java, id=58036, stack(0x00000000250f0000,0x00000000251f0000)]
Stack: [0x00000000250f0000,0x00000000251f0000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0x3152fa]
V [jvm.dll+0x265d03]
V [jvm.dll+0x266943]
V [jvm.dll+0x25e1e6]
V [jvm.dll+0x21247e]
V [jvm.dll+0x283070]
V [jvm.dll+0x315188]
C [ntdll.dll+0x29d0d]
C [ntdll.dll+0x191af]
C [ntdll.dll+0x51278]
C 0x00000000015a3eb0
--------------- P R O C E S S ---------------
Java Threads: ( => current thread )
0x000000001f35f800 JavaThread "Abandoned connection cleanup thread" daemon [_thread_blocked, id=55380, stack(0x0000000025b20000,0x0000000025c20000)]
0x000000001f35e800 JavaThread "http-nio-443-exec-10" daemon [_thread_blocked, id=29756, stack(0x0000000025a20000,0x0000000025b20000)]
0x000000001f35e000 JavaThread "http-nio-443-exec-9" daemon [_thread_blocked, id=56276, stack(0x0000000025920000,0x0000000025a20000)]
0x000000001f35d000 JavaThread "http-nio-443-exec-8" daemon [_thread_blocked, id=52324, stack(0x0000000025820000,0x0000000025920000)]
0x000000001f35c800 JavaThread "http-nio-443-exec-7" daemon [_thread_blocked, id=69708, stack(0x0000000025520000,0x0000000025620000)]
0x000000001f35b800 JavaThread "http-nio-443-exec-6" daemon [_thread_blocked, id=58736, stack(0x0000000025420000,0x0000000025520000)]
0x000000001f35a800 JavaThread "http-nio-443-exec-5" daemon [_thread_blocked, id=67540, stack(0x0000000025320000,0x0000000025420000)]
=>0x000000001f35a000 JavaThread "http-nio-443-exec-4" daemon [_thread_in_Java, id=58036, stack(0x00000000250f0000,0x00000000251f0000)]
0x000000001f359000 JavaThread "http-nio-443-exec-3" daemon [_thread_blocked, id=70244, stack(0x0000000024ff0000,0x00000000250f0000)]
0x000000001f358800 JavaThread "http-nio-443-exec-1" daemon [_thread_blocked, id=62668, stack(0x0000000024ef0000,0x0000000024ff0000)]
0x000000001f357800 JavaThread "http-nio-443-exec-2" daemon [_thread_blocked, id=75172, stack(0x0000000024df0000,0x0000000024ef0000)]
0x000000001f357000 JavaThread "ajp-apr-8009-AsyncTimeout" daemon [_thread_blocked, id=75644, stack(0x0000000024cf0000,0x0000000024df0000)]
0x000000001f356000 JavaThread "ajp-apr-8009-Acceptor-0" daemon [_thread_in_native, id=56716, stack(0x0000000024bf0000,0x0000000024cf0000)]
0x000000001f355800 JavaThread "ajp-apr-8009-Poller" daemon [_thread_blocked, id=13888, stack(0x0000000024af0000,0x0000000024bf0000)]
0x000000001f354800 JavaThread "http-nio-443-Acceptor-0" daemon [_thread_in_native, id=11620, stack(0x00000000249f0000,0x0000000024af0000)]
0x000000001f354000 JavaThread "http-nio-443-ClientPoller-1" daemon [_thread_blocked, id=67892, stack(0x00000000248f0000,0x00000000249f0000)]
0x000000001f353000 JavaThread "http-nio-443-ClientPoller-0" daemon [_thread_blocked, id=61096, stack(0x00000000247f0000,0x00000000248f0000)]
0x000000001f352800 JavaThread "http-apr-80-AsyncTimeout" daemon [_thread_blocked, id=37252, stack(0x00000000246f0000,0x00000000247f0000)]
0x000000001f351800 JavaThread "http-apr-80-Acceptor-0" daemon [_thread_in_native, id=69244, stack(0x00000000245f0000,0x00000000246f0000)]
0x000000001f351000 JavaThread "http-apr-80-Sendfile" daemon [_thread_blocked, id=59272, stack(0x00000000244f0000,0x00000000245f0000)]
0x000000001f350000 JavaThread "http-apr-80-Poller" daemon [_thread_blocked, id=58848, stack(0x00000000243f0000,0x00000000244f0000)]
0x000000001c9ab800 JavaThread "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon [_thread_blocked, id=61180, stack(0x00000000240f0000,0x00000000241f0000)]
0x000000001dbb1800 JavaThread "NioBlockingSelector.BlockPoller-1" daemon [_thread_blocked, id=73824, stack(0x000000001ec20000,0x000000001ed20000)]
0x000000001d863800 JavaThread "GC Daemon" daemon [_thread_blocked, id=72656, stack(0x000000001e720000,0x000000001e820000)]
0x000000001c544000 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=55972, stack(0x000000001d350000,0x000000001d450000)]
0x000000001c543000 JavaThread "RMI TCP Accept-8989" daemon [_thread_in_native, id=74780, stack(0x000000001d250000,0x000000001d350000)]
0x000000001c4fb000 JavaThread "RMI TCP Accept-0" daemon [_thread_in_native, id=10568, stack(0x000000001d0c0000,0x000000001d1c0000)]
0x00000000190a0000 JavaThread "AsyncFileHandlerWriter-1554874502" daemon [_thread_blocked, id=52468, stack(0x000000001c360000,0x000000001c460000)]
0x0000000019006800 JavaThread "Service Thread" daemon [_thread_blocked, id=51704, stack(0x000000001c260000,0x000000001c360000)]
0x0000000018ffd000 JavaThread "C1 CompilerThread11" daemon [_thread_blocked, id=68832, stack(0x000000001c160000,0x000000001c260000)]
0x0000000018ff4000 JavaThread "C1 CompilerThread10" daemon [_thread_blocked, id=68440, stack(0x000000001c060000,0x000000001c160000)]
0x0000000018fdf800 JavaThread "C1 CompilerThread9" daemon [_thread_blocked, id=52296, stack(0x000000001be60000,0x000000001bf60000)]
0x0000000018fd5000 JavaThread "C1 CompilerThread8" daemon [_thread_blocked, id=30764, stack(0x000000001bd60000,0x000000001be60000)]
0x0000000018fcc800 JavaThread "C2 CompilerThread7" daemon [_thread_blocked, id=72552, stack(0x000000001bc60000,0x000000001bd60000)]
0x0000000018fc3800 JavaThread "C2 CompilerThread6" daemon [_thread_blocked, id=71164, stack(0x000000001bb60000,0x000000001bc60000)]
0x0000000018fb3000 JavaThread "C2 CompilerThread5" daemon [_thread_blocked, id=69740, stack(0x000000001ba60000,0x000000001bb60000)]
0x0000000018fa8000 JavaThread "C2 CompilerThread4" daemon [_thread_blocked, id=70456, stack(0x000000001b960000,0x000000001ba60000)]
0x0000000018f85000 JavaThread "C2 CompilerThread3" daemon [_thread_blocked, id=52596, stack(0x000000001b860000,0x000000001b960000)]
0x0000000018f5b800 JavaThread "C2 CompilerThread2" daemon [_thread_blocked, id=68636, stack(0x000000001b760000,0x000000001b860000)]
0x0000000018f53000 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=51656, stack(0x000000001b660000,0x000000001b760000)]
0x0000000018f46000 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=61940, stack(0x000000001b560000,0x000000001b660000)]
0x0000000018f43800 JavaThread "Attach Listener" daemon [_thread_blocked, id=54868, stack(0x000000001b460000,0x000000001b560000)]
0x0000000018f42800 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=42768, stack(0x000000001b360000,0x000000001b460000)]
0x0000000018efb000 JavaThread "Finalizer" daemon [_thread_blocked, id=69772, stack(0x000000001b260000,0x000000001b360000)]
0x0000000018ef4800 JavaThread "Reference Handler" daemon [_thread_blocked, id=26356, stack(0x000000001b160000,0x000000001b260000)]
0x0000000001451800 JavaThread "main" [_thread_in_native, id=70896, stack(0x0000000001350000,0x0000000001450000)]
Other Threads:
0x0000000016fb5000 VMThread [stack: 0x000000001b060000,0x000000001b160000] [id=68824]
0x000000001c545000 WatcherThread [stack: 0x000000001d450000,0x000000001d550000] [id=57612]
VM state:synchronizing (normal execution)
VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event])
[0x000000000129ded0] Safepoint_lock - owner thread: 0x0000000016fb5000
[0x000000000129df50] Threads_lock - owner thread: 0x0000000016fb5000
Heap:
PSYoungGen total 325632K, used 59101K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 322048K, 17% used [0x00000000d5580000,0x00000000d8c00500,0x00000000e9000000)
from space 3584K, 91% used [0x00000000e9000000,0x00000000e9337088,0x00000000e9380000)
to space 200192K, 0% used [0x00000000f3c80000,0x00000000f3c80000,0x0000000100000000)
ParOldGen total 1398272K, used 45176K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 3% used [0x0000000080000000,0x0000000082c1e1a8,0x00000000d5580000)
Metaspace used 24212K, capacity 24780K, committed 24960K, reserved 1071104K
class space used 2531K, capacity 2660K, committed 2688K, reserved 1048576K
Card table byte_map: [0x0000000010910000,0x0000000010d20000] byte_map_base: 0x0000000010510000
Marking Bits: (ParMarkBitMap*) 0x000000006feeb460
Begin Bits: [0x00000000121d0000, 0x00000000141d0000)
End Bits: [0x00000000141d0000, 0x00000000161d0000)
Polling page: 0x0000000000440000
CodeCache: size=245760Kb used=14452Kb max_used=14452Kb free=231307Kb
bounds [0x0000000001550000, 0x0000000002390000, 0x0000000010550000]
total_blobs=4191 nmethods=3701 adapters=401
compilation: enabled
Compilation events (10 events):
Event: 50.173 Thread 0x0000000018fdf800 nmethod 4344 0x0000000001d44950 code [0x0000000001d44b00, 0x0000000001d44ff8]
Event: 50.173 Thread 0x0000000018fdf800 4347 3 com.sun.crypto.provider.CipherCore::getKeyBytes (61 bytes)
Event: 50.173 Thread 0x0000000018ff4000 nmethod 4346 0x0000000001d44450 code [0x0000000001d445c0, 0x0000000001d44838]
Event: 50.173 Thread 0x0000000018fd5000 4348 3 com.sun.crypto.provider.AESCrypt::init (121 bytes)
Event: 50.173 Thread 0x0000000018fdf800 nmethod 4347 0x000000000235d910 code [0x000000000235dae0, 0x000000000235e0f8]
Event: 50.174 Thread 0x0000000018fd5000 nmethod 4348 0x00000000023805d0 code [0x0000000002380860, 0x0000000002381a08]
Event: 50.175 Thread 0x0000000018fdf800 4349 s 1 sun.security.ssl.SSLEngineImpl::getConnectionState (5 bytes)
Event: 50.175 Thread 0x0000000018fdf800 nmethod 4349 0x00000000020cafd0 code [0x00000000020cb120, 0x00000000020cb390]
Event: 50.175 Thread 0x0000000018ffd000 4350 3 com.sun.crypto.provider.AESCipher::engineDoFinal (15 bytes)
Event: 50.175 Thread 0x0000000018ffd000 nmethod 4350 0x000000000235d4d0 code [0x000000000235d640, 0x000000000235d848]
GC Heap History (10 events):
Event: 11.794 GC heap before
{Heap before GC invocations=4 (full 0):
PSYoungGen total 611840K, used 611819K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 524800K, 100% used [0x00000000d5580000,0x00000000f5600000,0x00000000f5600000)
from space 87040K, 99% used [0x00000000f5600000,0x00000000faafad58,0x00000000fab00000)
to space 87040K, 0% used [0x00000000fab00000,0x00000000fab00000,0x0000000100000000)
ParOldGen total 1398272K, used 93837K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 6% used [0x0000000080000000,0x0000000085ba3768,0x00000000d5580000)
Metaspace used 17054K, capacity 17318K, committed 17664K, reserved 1064960K
class space used 1900K, capacity 2001K, committed 2048K, reserved 1048576K
Event: 12.055 GC heap after
Heap after GC invocations=4 (full 0):
PSYoungGen total 611840K, used 87030K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 524800K, 0% used [0x00000000d5580000,0x00000000d5580000,0x00000000f5600000)
from space 87040K, 99% used [0x00000000fab00000,0x00000000ffffd860,0x0000000100000000)
to space 87040K, 0% used [0x00000000f5600000,0x00000000f5600000,0x00000000fab00000)
ParOldGen total 1398272K, used 158074K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 11% used [0x0000000080000000,0x0000000089a5e998,0x00000000d5580000)
Metaspace used 17054K, capacity 17318K, committed 17664K, reserved 1064960K
class space used 1900K, capacity 2001K, committed 2048K, reserved 1048576K
}
Event: 14.184 GC heap before
{Heap before GC invocations=5 (full 0):
PSYoungGen total 611840K, used 611830K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 524800K, 100% used [0x00000000d5580000,0x00000000f5600000,0x00000000f5600000)
from space 87040K, 99% used [0x00000000fab00000,0x00000000ffffd860,0x0000000100000000)
to space 87040K, 0% used [0x00000000f5600000,0x00000000f5600000,0x00000000fab00000)
ParOldGen total 1398272K, used 158074K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 11% used [0x0000000080000000,0x0000000089a5e998,0x00000000d5580000)
Metaspace used 17500K, capacity 17906K, committed 18048K, reserved 1064960K
class space used 1939K, capacity 2053K, committed 2176K, reserved 1048576K
Event: 14.249 GC heap after
Heap after GC invocations=5 (full 0):
PSYoungGen total 611840K, used 87011K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 524800K, 0% used [0x00000000d5580000,0x00000000d5580000,0x00000000f5600000)
from space 87040K, 99% used [0x00000000f5600000,0x00000000faaf8e10,0x00000000fab00000)
to space 87040K, 0% used [0x00000000fab00000,0x00000000fab00000,0x0000000100000000)
ParOldGen total 1398272K, used 176746K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 12% used [0x0000000080000000,0x000000008ac9ab80,0x00000000d5580000)
Metaspace used 17500K, capacity 17906K, committed 18048K, reserved 1064960K
class space used 1939K, capacity 2053K, committed 2176K, reserved 1048576K
}
Event: 14.930 GC heap before
{Heap before GC invocations=6 (full 0):
PSYoungGen total 611840K, used 193799K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 524800K, 20% used [0x00000000d5580000,0x00000000dbdc9108,0x00000000f5600000)
from space 87040K, 99% used [0x00000000f5600000,0x00000000faaf8e10,0x00000000fab00000)
to space 87040K, 0% used [0x00000000fab00000,0x00000000fab00000,0x0000000100000000)
ParOldGen total 1398272K, used 176746K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 12% used [0x0000000080000000,0x000000008ac9ab80,0x00000000d5580000)
Metaspace used 20735K, capacity 21130K, committed 21296K, reserved 1069056K
class space used 2301K, capacity 2418K, committed 2432K, reserved 1048576K
Event: 14.962 GC heap after
Heap after GC invocations=6 (full 0):
PSYoungGen total 409088K, used 50523K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 322048K, 0% used [0x00000000d5580000,0x00000000d5580000,0x00000000e9000000)
from space 87040K, 58% used [0x00000000fab00000,0x00000000fdc56ea8,0x0000000100000000)
to space 188416K, 0% used [0x00000000e9000000,0x00000000e9000000,0x00000000f4800000)
ParOldGen total 1398272K, used 176754K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 12% used [0x0000000080000000,0x000000008ac9cb80,0x00000000d5580000)
Metaspace used 20735K, capacity 21130K, committed 21296K, reserved 1069056K
class space used 2301K, capacity 2418K, committed 2432K, reserved 1048576K
}
Event: 14.962 GC heap before
{Heap before GC invocations=7 (full 1):
PSYoungGen total 409088K, used 50523K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 322048K, 0% used [0x00000000d5580000,0x00000000d5580000,0x00000000e9000000)
from space 87040K, 58% used [0x00000000fab00000,0x00000000fdc56ea8,0x0000000100000000)
to space 188416K, 0% used [0x00000000e9000000,0x00000000e9000000,0x00000000f4800000)
ParOldGen total 1398272K, used 176754K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 12% used [0x0000000080000000,0x000000008ac9cb80,0x00000000d5580000)
Metaspace used 20735K, capacity 21130K, committed 21296K, reserved 1069056K
class space used 2301K, capacity 2418K, committed 2432K, reserved 1048576K
Event: 15.024 GC heap after
Heap after GC invocations=7 (full 1):
PSYoungGen total 409088K, used 0K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 322048K, 0% used [0x00000000d5580000,0x00000000d5580000,0x00000000e9000000)
from space 87040K, 0% used [0x00000000fab00000,0x00000000fab00000,0x0000000100000000)
to space 188416K, 0% used [0x00000000e9000000,0x00000000e9000000,0x00000000f4800000)
ParOldGen total 1398272K, used 45168K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 3% used [0x0000000080000000,0x0000000082c1c1a8,0x00000000d5580000)
Metaspace used 20734K, capacity 21128K, committed 21296K, reserved 1069056K
class space used 2301K, capacity 2417K, committed 2432K, reserved 1048576K
}
Event: 21.576 GC heap before
{Heap before GC invocations=8 (full 1):
PSYoungGen total 409088K, used 322048K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 322048K, 100% used [0x00000000d5580000,0x00000000e9000000,0x00000000e9000000)
from space 87040K, 0% used [0x00000000fab00000,0x00000000fab00000,0x0000000100000000)
to space 188416K, 0% used [0x00000000e9000000,0x00000000e9000000,0x00000000f4800000)
ParOldGen total 1398272K, used 45168K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 3% used [0x0000000080000000,0x0000000082c1c1a8,0x00000000d5580000)
Metaspace used 23523K, capacity 24056K, committed 24192K, reserved 1071104K
class space used 2500K, capacity 2619K, committed 2688K, reserved 1048576K
Event: 21.580 GC heap after
Heap after GC invocations=8 (full 1):
PSYoungGen total 325632K, used 3292K [0x00000000d5580000, 0x0000000100000000, 0x0000000100000000)
eden space 322048K, 0% used [0x00000000d5580000,0x00000000d5580000,0x00000000e9000000)
from space 3584K, 91% used [0x00000000e9000000,0x00000000e9337088,0x00000000e9380000)
to space 200192K, 0% used [0x00000000f3c80000,0x00000000f3c80000,0x0000000100000000)
ParOldGen total 1398272K, used 45176K [0x0000000080000000, 0x00000000d5580000, 0x00000000d5580000)
object space 1398272K, 3% used [0x0000000080000000,0x0000000082c1e1a8,0x00000000d5580000)
Metaspace used 23523K, capacity 24056K, committed 24192K, reserved 1071104K
class space used 2500K, capacity 2619K, committed 2688K, reserved 1048576K
}
Deoptimization events (10 events):
Event: 21.512 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001832a10 method=com.mysql.jdbc.ResultSetImpl.extractStringFromNativeColumn(II)Ljava/lang/String; @ 14
Event: 21.760 Thread 0x000000001f35d000 Uncommon trap: reason=unreached action=reinterpret pc=0x0000000001d33e2c method=sun.util.calendar.ZoneInfo.getOffsets(J[II)I @ 112
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cf0dec method=com.mysql.jdbc.RowDataStatic.next()Lcom/mysql/jdbc/ResultSetRow; @ 39
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cf0d24 method=com.mysql.jdbc.ResultSetImpl.next()Z @ 70
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cef6c0 method=com.mysql.jdbc.RowDataStatic.next()Lcom/mysql/jdbc/ResultSetRow; @ 39
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cf0d24 method=com.mysql.jdbc.ResultSetImpl.next()Z @ 70
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cef6c0 method=com.mysql.jdbc.RowDataStatic.next()Lcom/mysql/jdbc/ResultSetRow; @ 39
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cf0d24 method=com.mysql.jdbc.ResultSetImpl.next()Z @ 70
Event: 21.769 Thread 0x000000001f35d000 Uncommon trap: reason=class_check action=maybe_recompile pc=0x0000000001cf0d24 method=com.mysql.jdbc.ResultSetImpl.next()Z @ 70
Event: 26.682 Thread 0x000000001f35a000 Uncommon trap: reason=unreached action=reinterpret pc=0x0000000001e65818 method=java.lang.StringBuffer.toString()Ljava/lang/String; @ 4
Internal exceptions (10 events):
Event: 25.967 Thread 0x000000001f35a000 Exception <a 'java/lang/ArrayIndexOutOfBoundsException'> (0x00000000d7f503e0) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\runtime\sharedRuntime.cpp, line 604]
Event: 29.279 Thread 0x000000001f358800 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d8344e58) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 29.279 Thread 0x000000001f358800 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d8345a90) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 29.279 Thread 0x000000001f358800 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d834a2c8) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 33.045 Thread 0x000000001f357800 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d844ad50) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 33.045 Thread 0x000000001f357800 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d844b988) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 33.045 Thread 0x000000001f357800 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d84501c0) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 40.000 Thread 0x000000001f35d000 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d721ab58) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 40.000 Thread 0x000000001f35d000 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d721b610) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Event: 40.001 Thread 0x000000001f35d000 Exception <a 'java/security/PrivilegedActionException'> (0x00000000d721ee48) thrown at [D:\re\workspace\8-2-build-windows-amd64-cygwin\jdk8u20\1074\hotspot\src\share\vm\prims\jvm.cpp, line 1275]
Events (10 events):
Event: 39.917 Executing VM operation: RevokeBias
Event: 39.917 Executing VM operation: RevokeBias done
Event: 39.918 Thread 0x0000000018fdf800 flushing nmethod 0x0000000001c79b90
Event: 39.919 Thread 0x0000000018fd5000 flushing nmethod 0x0000000001d44450
Event: 40.000 loading class com/mtg/mtg/controller/event/modules/core/Login
Event: 40.000 loading class com/mtg/mtg/controller/event/modules/core/Login done
Event: 40.007 Thread 0x0000000018ff4000 flushing nmethod 0x00000000020cafd0
Event: 40.007 Thread 0x0000000018ff4000 flushing nmethod 0x00000000020cd390
Event: 40.008 Thread 0x0000000018f5b800 flushing nmethod 0x00000000021dcf10
Event: 40.008 Thread 0x0000000018f5b800 flushing nmethod 0x00000000021f0e10
Dynamic libraries:
0x0000000140000000 - 0x000000014001e000 C:\Program Files\Apache Software Foundation\Tomcat 8.0\bin\Tomcat8.exe
0x0000000077c00000 - 0x0000000077da9000 C:\Windows\SYSTEM32\ntdll.dll
0x00000000779e0000 - 0x0000000077aff000 C:\Windows\system32\kernel32.dll
0x000007fefdc40000 - 0x000007fefdcab000 C:\Windows\system32\KERNELBASE.dll
0x000007feff890000 - 0x000007feff96b000 C:\Windows\system32\ADVAPI32.dll
0x000007feff970000 - 0x000007feffa0f000 C:\Windows\system32\msvcrt.dll
0x000007feffd50000 - 0x000007feffd6f000 C:\Windows\SYSTEM32\sechost.dll
0x000007feffb20000 - 0x000007feffc4d000 C:\Windows\system32\RPCRT4.dll
0x000007fefe0f0000 - 0x000007fefee78000 C:\Windows\system32\SHELL32.dll
0x000007feff480000 - 0x000007feff4f1000 C:\Windows\system32\SHLWAPI.dll
0x000007feff7c0000 - 0x000007feff827000 C:\Windows\system32\GDI32.dll
0x0000000077b00000 - 0x0000000077bfa000 C:\Windows\system32\USER32.dll
0x000007feff210000 - 0x000007feff21e000 C:\Windows\system32\LPK.dll
0x000007feffd80000 - 0x000007feffe49000 C:\Windows\system32\USP10.dll
0x000007feffc50000 - 0x000007feffc7e000 C:\Windows\system32\IMM32.DLL
0x000007feffa10000 - 0x000007feffb19000 C:\Windows\system32\MSCTF.dll
0x000000006f710000 - 0x000000006ff68000 C:\Program Files\Java\jre1.8.0_20\bin\server\jvm.dll
0x000007fefa490000 - 0x000007fefa499000 C:\Windows\system32\WSOCK32.dll
0x000007feffd00000 - 0x000007feffd4d000 C:\Windows\system32\WS2_32.dll
0x000007feffd70000 - 0x000007feffd78000 C:\Windows\system32\NSI.dll
0x000007fef7ba0000 - 0x000007fef7bdb000 C:\Windows\system32\WINMM.dll
0x0000000077dd0000 - 0x0000000077dd7000 C:\Windows\system32\PSAPI.DLL
0x0000000054fd0000 - 0x00000000550a2000 C:\Program Files\Java\jre1.8.0_20\bin\MSVCR100.dll
0x00000000668c0000 - 0x00000000668cf000 C:\Program Files\Java\jre1.8.0_20\bin\verify.dll
0x00000000567d0000 - 0x00000000567f8000 C:\Program Files\Java\jre1.8.0_20\bin\java.dll
0x0000000057880000 - 0x0000000057896000 C:\Program Files\Java\jre1.8.0_20\bin\zip.dll
0x000007fefee80000 - 0x000007feff083000 C:\Windows\system32\ole32.dll
0x000007fefdb50000 - 0x000007fefdb5f000 C:\Windows\system32\profapi.dll
0x000000006e440000 - 0x000000006e44d000 C:\Program Files\Java\jre1.8.0_20\bin\management.dll
0x00000000661d0000 - 0x00000000661ea000 C:\Program Files\Java\jre1.8.0_20\bin\net.dll
0x000007fefd2f0000 - 0x000007fefd345000 C:\Windows\system32\mswsock.dll
0x000007fefd4c0000 - 0x000007fefd4c7000 C:\Windows\System32\wship6.dll
0x0000000055bf0000 - 0x0000000055c01000 C:\Program Files\Java\jre1.8.0_20\bin\nio.dll
0x000007fefc6b0000 - 0x000007fefc6c5000 C:\Windows\system32\NLAapi.dll
0x000007fefb410000 - 0x000007fefb425000 C:\Windows\system32\napinsp.dll
0x000007fefd180000 - 0x000007fefd1db000 C:\Windows\system32\DNSAPI.dll
0x000007fefb440000 - 0x000007fefb44b000 C:\Windows\System32\winrnr.dll
0x000007fefcd20000 - 0x000007fefcd27000 C:\Windows\System32\wshtcpip.dll
0x000007fefbfa0000 - 0x000007fefbfc7000 C:\Windows\system32\IPHLPAPI.DLL
0x000007fefbf10000 - 0x000007fefbf1b000 C:\Windows\system32\WINNSI.DLL
0x000007fefb530000 - 0x000007fefb538000 C:\Windows\system32\rasadhlp.dll
0x000007fefbe00000 - 0x000007fefbe53000 C:\Windows\System32\fwpuclnt.dll
0x000007fefd5c0000 - 0x000007fefd5d7000 C:\Windows\system32\CRYPTSP.dll
0x000007fefd0b0000 - 0x000007fefd0f7000 C:\Windows\system32\rsaenh.dll
0x000007fefda40000 - 0x000007fefda4f000 C:\Windows\system32\CRYPTBASE.dll
0x000007fefbc00000 - 0x000007fefbc11000 C:\Windows\system32\dhcpcsvc6.DLL
0x000007fefbbe0000 - 0x000007fefbbf8000 C:\Windows\system32\dhcpcsvc.DLL
0x0000000180000000 - 0x000000018018c000 C:\Program Files\Apache Software Foundation\Tomcat 8.0\bin\tcnative-1.dll
0x0000000055bc0000 - 0x0000000055be4000 C:\Program Files\Java\jre1.8.0_20\bin\sunec.dll
0x0000000064930000 - 0x000000006493b000 C:\Program Files\Java\jre1.8.0_20\bin\sunmscapi.dll
0x000007fefdcb0000 - 0x000007fefde17000 C:\Windows\system32\CRYPT32.dll
0x000007fefdbf0000 - 0x000007fefdbff000 C:\Windows\system32\MSASN1.dll
0x000007fefb2a0000 - 0x000007fefb3c5000 C:\Windows\system32\DBGHELP.DLL
VM Arguments:
jvm_args: -Dcatalina.home=C:\Program Files\Apache Software Foundation\Tomcat 8.0 -Dcatalina.base=C:\Program Files\Apache Software Foundation\Tomcat 8.0 -Djava.endorsed.dirs=C:\Program Files\Apache Software Foundation\Tomcat 8.0\endorsed -Djava.io.tmpdir=C:\Program Files\Apache Software Foundation\Tomcat 8.0\temp -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file=C:\Program Files\Apache Software Foundation\Tomcat 8.0\conf\logging.properties -Duser.timezone=CST -Dcom.sun.management.jmxremote.port=8989 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false exit -Xms2048m -Xmx2048m
java_command: <unknown>
java_class_path (initial): C:\Program Files\Apache Software Foundation\Tomcat 8.0\bin\bootstrap.jar;C:\Program Files\Apache Software Foundation\Tomcat 8.0\bin\tomcat-juli.jar
Launcher Type: generic
Environment Variables:
PATH=C:\ProgramData\Oracle\Java\javapath;C:\Program Files (x86)\Windows Resource Kits\Tools\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files (x86)\MySQL\MySQL Utilities 1.3.6\;C:\Program Files\MySQL\MySQL Server 5.6\bin;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\;c:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files\Microsoft SQL Server\100\Tools\Binn\;c:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\;
USERNAME=MTGWEB1$
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 44 Stepping 2, GenuineIntel
--------------- S Y S T E M ---------------
OS: Windows Server 2008 R2 , 64 bit Build 7601 Service Pack 1
CPU:total 24 (6 cores per cpu, 2 threads per core) family 6 model 44 stepping 2, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1, sse4.2, popcnt, aes, clmul, ht, tsc, tscinvbit, tscinv
Memory: 4k page, physical 8388608k(8388608k free), swap 134189436k(90292236k free)
vm_info: Java HotSpot(TM) 64-Bit Server VM (25.20-b23) for windows-amd64 JRE (1.8.0_20-b26), built on Jul 30 2014 13:51:23 by "java_re" with MS VC++ 10.0 (VS2010)
time: Thu Oct 02 12:04:37 2014
elapsed time: 52 seconds (0d 0h 0m 52s)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Chad Maniccia <CM...@mbgaustin.com>.
I figured as much I'm trying to build something right now to show case this oddity.
________________________________________
From: Mark Thomas <ma...@apache.org>
Sent: Friday, October 03, 2014 1:50 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
On 03/10/2014 19:38, Chad Maniccia wrote:
> Hi Mark,
>
> Thanks for replying. I actually reported this bug to Oracle before contacting this group. They contacted me once but then never replied again. I'd appreciate it if you could bring it to their attention again.
>
> https://bugs.openjdk.java.net/browse/JDK-8058284
Happy to do that once you have a repeatable test case. Frankly, without
one, I doubt this is going to get much attention.
Mark
>
> This bug is kind of elusive as a form that is crashing today might not crash tomorrow, I suspect it is because headers, cookies, session keys etc have changed. I'll see if I can reproduce it by creating a testing form.
>
> Can anyone tell me why this line causes the site to not crash?
>
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>
> P.S.
> Igal thanks for your support.
> ________________________________________
> From: Mark Thomas <ma...@apache.org>
> Sent: Friday, October 03, 2014 1:14 PM
> To: Tomcat Users List
> Subject: Re: Tomcat JVM Crash
>
> On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
>>> regardless of whose fault this is, Tomcat should be patched so that it
>>> doesn't crash.
>
> The general position of the Tomcat developers is that we do *not* patch
> Tomcat to work around bugs in third party code.
>
> There have been exceptions in the past but - since this JVM bug as a
> workaround available - I very much doubt that Tomcat will be patched to
> avoid this (even if such a patch was possible which looks unlikely).
>
>> can you produce a reduced test case so that the good people at Tomcat
>> can reproduce it on their end and patch it?
>
> A reproducible test case is definitely a good thing but it needs to go
> to Oracle, not to the Tomcat devs.
>
> Note we do have some contacts with Oracle we can use to ensure a bug
> report gets in front of the right people.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Ognjen Blagojevic <og...@gmail.com>.
Chad,
On 10.10.2014 18:12, Chad Maniccia wrote:
> I have reported my findings to Oracle. They need to fix the bug, but for us the best solution was just to move away from JSSE and switch to APR OpenSSL which is the recommend solution to begin with.
Thank you for reporting that back to us.
Could you also send bug ID, so other interested Tomcat users may keep
track of the problem?
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Alexander Scheibe <al...@meetingsphere.com>.
Hi,
I also have this problem appearing every several weeks. And had also
reported this to Oracle some time ago but never got any feedback.
I have now found an example JSP which always always crashes the JVM for me
on Linux and Windows.
I limited the list of ciphers to only GCM cipher suites
(TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256)
and called this JSP:
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Demo</title>
</head>
<body>
<%
StringBuffer sb = (StringBuffer) session.getAttribute("string-buffer");
if(null == sb) {
sb = new StringBuffer();
session.setAttribute("string-buffer", sb);
}
sb.append("X");
System.out.printf("Buffer length is %d\n", sb.length());
%>
Hello
<form action="/jvmCrashTest.jsp" method="post" id="theForm">
<input type="hidden" name="uplinkType" value="rev"/>
<input type="hidden" name="content"
value="<%=sb.toString()%>"/>
<input type="submit" value="Send"/>
</form>
</body>
</html>
After about 4073 request the JVM crashes.
Doesn't matter if the JSP gets called from Chrome or Internet Explorer
I reported my reproduction to Oracle too, but since you Chad seams to be in
contact with them you could point them to this post.
Thanks,
Alexander
--
View this message in context: http://tomcat.10.x6.nabble.com/Tomcat-JVM-Crash-tp5022790p5025871.html
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Chad Maniccia <CM...@mbgaustin.com>.
Hi,
So I have found a long term solution to our crash problem. We were using JSSE for SSL, switching to APR and OpenSSL fixed the problems. So my findings are this....
JSSE has a bug in it that can cause the Tomcat server to crash brought on by SSL, Chrome and a form post of a specific amount of data. The server crashes can be mitigated by starting Tomcat with "-XX:CompileCommand=exclude,com/sun/crypto/provider/*.*". Instead of the server crashing Chrome returns net::ERR_SSL_PROTOCOL_ERROR and you can actually catch the error, the stack trace is below.
I have reported my findings to Oracle. They need to fix the bug, but for us the best solution was just to move away from JSSE and switch to APR OpenSSL which is the recommend solution to begin with.
Thanks,
Chad
07-Oct-2014 10:10:58.057 SEVERE [http-nio-443-exec-38] org.apache.catalina.core.StandardWrapperValve.invoke Servlet.service() for servlet [Controller] in context with path [/mtg] threw exception
java.lang.NullPointerException
at java.lang.System.arraycopy(Native Method)
at com.sun.crypto.provider.GCTR.reset(GCTR.java:125)
at com.sun.crypto.provider.GCTR.doFinal(GCTR.java:116)
at com.sun.crypto.provider.GaloisCounterMode.doLastBlock(GaloisCounterMode.java:343)
at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:511)
at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1023)
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:960)
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:479)
at javax.crypto.CipherSpi.bufferCrypt(CipherSpi.java:830)
at javax.crypto.CipherSpi.engineDoFinal(CipherSpi.java:730)
at javax.crypto.Cipher.doFinal(Cipher.java:2416)
at sun.security.ssl.CipherBox.decrypt(Unknown Source)
at sun.security.ssl.EngineInputRecord.decrypt(Unknown Source)
at sun.security.ssl.SSLEngineImpl.readRecord(Unknown Source)
at sun.security.ssl.SSLEngineImpl.readNetRecord(Unknown Source)
at sun.security.ssl.SSLEngineImpl.unwrap(Unknown Source)
at javax.net.ssl.SSLEngine.unwrap(Unknown Source)
at org.apache.tomcat.util.net.SecureNioChannel.read(SecureNioChannel.java:439)
at org.apache.tomcat.util.net.NioBlockingSelector.read(NioBlockingSelector.java:173)
at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:251)
at org.apache.tomcat.util.net.NioSelectorPool.read(NioSelectorPool.java:232)
at org.apache.coyote.http11.InternalNioInputBuffer.fill(InternalNioInputBuffer.java:133)
at org.apache.coyote.http11.InternalNioInputBuffer$SocketInputBuffer.doRead(InternalNioInputBuffer.java:177)
at org.apache.coyote.http11.filters.IdentityInputFilter.doRead(IdentityInputFilter.java:110)
at org.apache.coyote.http11.AbstractInputBuffer.doRead(AbstractInputBuffer.java:413)
at org.apache.coyote.Request.doRead(Request.java:459)
at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:338)
at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:395)
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:363)
at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:190)
at org.apache.catalina.connector.Request.readPostBody(Request.java:3034)
at org.apache.catalina.connector.Request.parseParameters(Request.java:2983)
at org.apache.catalina.connector.Request.getParameter(Request.java:1077)
at org.apache.catalina.connector.RequestFacade.getParameter(RequestFacade.java:380)
at com.mtg.mtg.controller.Controller.doPost(Controller.java:41)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:644)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:725)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:291)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:239)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:219)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:142)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:610)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:537)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1081)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:658)
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:222)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1566)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1523)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
________________________________________
From: Mark Thomas <ma...@apache.org>
Sent: Friday, October 03, 2014 1:50 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
On 03/10/2014 19:38, Chad Maniccia wrote:
> Hi Mark,
>
> Thanks for replying. I actually reported this bug to Oracle before contacting this group. They contacted me once but then never replied again. I'd appreciate it if you could bring it to their attention again.
>
> https://bugs.openjdk.java.net/browse/JDK-8058284
Happy to do that once you have a repeatable test case. Frankly, without
one, I doubt this is going to get much attention.
Mark
>
> This bug is kind of elusive as a form that is crashing today might not crash tomorrow, I suspect it is because headers, cookies, session keys etc have changed. I'll see if I can reproduce it by creating a testing form.
>
> Can anyone tell me why this line causes the site to not crash?
>
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>
> P.S.
> Igal thanks for your support.
> ________________________________________
> From: Mark Thomas <ma...@apache.org>
> Sent: Friday, October 03, 2014 1:14 PM
> To: Tomcat Users List
> Subject: Re: Tomcat JVM Crash
>
> On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
>>> regardless of whose fault this is, Tomcat should be patched so that it
>>> doesn't crash.
>
> The general position of the Tomcat developers is that we do *not* patch
> Tomcat to work around bugs in third party code.
>
> There have been exceptions in the past but - since this JVM bug as a
> workaround available - I very much doubt that Tomcat will be patched to
> avoid this (even if such a patch was possible which looks unlikely).
>
>> can you produce a reduced test case so that the good people at Tomcat
>> can reproduce it on their end and patch it?
>
> A reproducible test case is definitely a good thing but it needs to go
> to Oracle, not to the Tomcat devs.
>
> Note we do have some contacts with Oracle we can use to ensure a bug
> report gets in front of the right people.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Mark Thomas <ma...@apache.org>.
On 03/10/2014 19:38, Chad Maniccia wrote:
> Hi Mark,
>
> Thanks for replying. I actually reported this bug to Oracle before contacting this group. They contacted me once but then never replied again. I'd appreciate it if you could bring it to their attention again.
>
> https://bugs.openjdk.java.net/browse/JDK-8058284
Happy to do that once you have a repeatable test case. Frankly, without
one, I doubt this is going to get much attention.
Mark
>
> This bug is kind of elusive as a form that is crashing today might not crash tomorrow, I suspect it is because headers, cookies, session keys etc have changed. I'll see if I can reproduce it by creating a testing form.
>
> Can anyone tell me why this line causes the site to not crash?
>
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>
> P.S.
> Igal thanks for your support.
> ________________________________________
> From: Mark Thomas <ma...@apache.org>
> Sent: Friday, October 03, 2014 1:14 PM
> To: Tomcat Users List
> Subject: Re: Tomcat JVM Crash
>
> On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
>>> regardless of whose fault this is, Tomcat should be patched so that it
>>> doesn't crash.
>
> The general position of the Tomcat developers is that we do *not* patch
> Tomcat to work around bugs in third party code.
>
> There have been exceptions in the past but - since this JVM bug as a
> workaround available - I very much doubt that Tomcat will be patched to
> avoid this (even if such a patch was possible which looks unlikely).
>
>> can you produce a reduced test case so that the good people at Tomcat
>> can reproduce it on their end and patch it?
>
> A reproducible test case is definitely a good thing but it needs to go
> to Oracle, not to the Tomcat devs.
>
> Note we do have some contacts with Oracle we can use to ensure a bug
> report gets in front of the right people.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Chad Maniccia <CM...@mbgaustin.com>.
Hi Christopher,
Appreciate the help. I figured the same on the slow down after reading a little bit about what turning off the JIT compiler would mean. But we are not experiencing a perceivable slow down. So for now its a good patch to prevent Tomcat crashing.
I don't have a working example of the crash, yesterday I could get it to crash reliably by opening a Lease in our Lease management system and trying to unlock it. Today it is no longer crashing. I'm creating a JavaScript page which will add more data to a form and submit it rinse and repeat to try and automate discovery of a crash.
It appears to just ignore the request. Chrome returns a blank page, I wish I would have hit F12 to see what was happening on the network.
Thanks,
Chad
________________________________________
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, October 03, 2014 1:59 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chad,
On 10/3/14 2:38 PM, Chad Maniccia wrote:
> Thanks for replying. I actually reported this bug to Oracle before
> contacting this group. They contacted me once but then never
> replied again. I'd appreciate it if you could bring it to their
> attention again.
>
> https://bugs.openjdk.java.net/browse/JDK-8058284
>
> This bug is kind of elusive as a form that is crashing today might
> not crash tomorrow, I suspect it is because headers, cookies,
> session keys etc have changed. I'll see if I can reproduce it by
> creating a testing form.
>
> Can anyone tell me why this line causes the site to not crash?
>
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
Whatever is going on inside of the crypto provider is causing
something (probably the JIT compiler) to crash. Or, the JIT compiler
is producing code that crashes... I don't know enough about how the
JVM works to know where compiled-in-memory code gets assigned a
"source library" in a stack dump.
Anyhow, using CompileCommand=exclude turns off the compiler for the
methods in the classes in the package indicated. That should mean that
everything in that package gets *interpreted*, which would probably
mean very slow performance since crypto work is usually pretty
processor-intensive and a JIT can really help a lot over interpreted
bytecode.
I wouldn't expect requests to be ignored in the cases where you have
disabled compilation to avoid the bug and then you try to trigger them.
What response does the client get in these cases? No response (waits
forever)? Empty response? What does a thread dump show for the thread
that is handling the request?
- -chris
> ________________________________________ From: Mark Thomas
> <ma...@apache.org> Sent: Friday, October 03, 2014 1:14 PM To:
> Tomcat Users List Subject: Re: Tomcat JVM Crash
>
> On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or
>>> Oracle? regardless of whose fault this is, Tomcat should be
>>> patched so that it doesn't crash.
>
> The general position of the Tomcat developers is that we do *not*
> patch Tomcat to work around bugs in third party code.
>
> There have been exceptions in the past but - since this JVM bug as
> a workaround available - I very much doubt that Tomcat will be
> patched to avoid this (even if such a patch was possible which
> looks unlikely).
>
>> can you produce a reduced test case so that the good people at
>> Tomcat can reproduce it on their end and patch it?
>
> A reproducible test case is definitely a good thing but it needs to
> go to Oracle, not to the Tomcat devs.
>
> Note we do have some contacts with Oracle we can use to ensure a
> bug report gets in front of the right people.
>
> Mark
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJULvIMAAoJEBzwKT+lPKRYGoEP/3xwimBkdsMXCiQ9WrKHL655
JU6zNsCKuAd9AGeWsteSzZkamDbcPBsVnjdiNgUMxwkEbCNONAlA6lOOGlB+LBDr
cZnDdLxkI2WrGkwclZ8fZ/IQFYI46EZ1CQOQ5xe5C5MYa6Ef1OwcQtvZtw6HFKGe
DnOD8+UFlK6gnXF/nqX/AqTxRJ4vusRBd3Jpqaqy7AecojL00lAQP0ORlQAvZ6Hj
KDhpJPIhV95qSLQTnOkkUF0JP+hafGC9iyBKmDfrDEI+zRYlaA/ARUe6sokBHKnO
Eashaih277N4sXq0YVjbAXZZrKJwK3uSyfkymwZjJFXY6dAa9w9PsfpQ2ck/doaK
BXsI9TOq7WwWOSLGkWm1OMeKBrtld26Doo8ukAhiQUANmTh3WNhgO1zK/KROFjOE
fqWJbubpiM6Rf+tl4nf4RcAV2pqfOO4atFk+YvtMxxLmQwPZ06OWwkypQzUxMOZb
yBSC5vEhZ6ODgT+jYMnghkzLD/FEm6UZLCU+xfGcb1iFOH6lNvXaw5/bxBfUnuuO
9+7wvw2TmZit6PAESj2msy3gS77JgaLOdrwk9GH3b4EZExLlqBTsY8n+HvfNL+qP
pkYlGl0SaWVnNlWYT3Y4pvLjs1MTrTZPUGD8sKz/6+YUdpyefIkuWVSjujEInOGx
EU9q8G4Zeg9GF4k7YaF3
=TdAU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Chad,
On 10/3/14 2:38 PM, Chad Maniccia wrote:
> Thanks for replying. I actually reported this bug to Oracle before
> contacting this group. They contacted me once but then never
> replied again. I'd appreciate it if you could bring it to their
> attention again.
>
> https://bugs.openjdk.java.net/browse/JDK-8058284
>
> This bug is kind of elusive as a form that is crashing today might
> not crash tomorrow, I suspect it is because headers, cookies,
> session keys etc have changed. I'll see if I can reproduce it by
> creating a testing form.
>
> Can anyone tell me why this line causes the site to not crash?
>
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
Whatever is going on inside of the crypto provider is causing
something (probably the JIT compiler) to crash. Or, the JIT compiler
is producing code that crashes... I don't know enough about how the
JVM works to know where compiled-in-memory code gets assigned a
"source library" in a stack dump.
Anyhow, using CompileCommand=exclude turns off the compiler for the
methods in the classes in the package indicated. That should mean that
everything in that package gets *interpreted*, which would probably
mean very slow performance since crypto work is usually pretty
processor-intensive and a JIT can really help a lot over interpreted
bytecode.
I wouldn't expect requests to be ignored in the cases where you have
disabled compilation to avoid the bug and then you try to trigger them.
What response does the client get in these cases? No response (waits
forever)? Empty response? What does a thread dump show for the thread
that is handling the request?
- -chris
> ________________________________________ From: Mark Thomas
> <ma...@apache.org> Sent: Friday, October 03, 2014 1:14 PM To:
> Tomcat Users List Subject: Re: Tomcat JVM Crash
>
> On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or
>>> Oracle? regardless of whose fault this is, Tomcat should be
>>> patched so that it doesn't crash.
>
> The general position of the Tomcat developers is that we do *not*
> patch Tomcat to work around bugs in third party code.
>
> There have been exceptions in the past but - since this JVM bug as
> a workaround available - I very much doubt that Tomcat will be
> patched to avoid this (even if such a patch was possible which
> looks unlikely).
>
>> can you produce a reduced test case so that the good people at
>> Tomcat can reproduce it on their end and patch it?
>
> A reproducible test case is definitely a good thing but it needs to
> go to Oracle, not to the Tomcat devs.
>
> Note we do have some contacts with Oracle we can use to ensure a
> bug report gets in front of the right people.
>
> Mark
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJULvIMAAoJEBzwKT+lPKRYGoEP/3xwimBkdsMXCiQ9WrKHL655
JU6zNsCKuAd9AGeWsteSzZkamDbcPBsVnjdiNgUMxwkEbCNONAlA6lOOGlB+LBDr
cZnDdLxkI2WrGkwclZ8fZ/IQFYI46EZ1CQOQ5xe5C5MYa6Ef1OwcQtvZtw6HFKGe
DnOD8+UFlK6gnXF/nqX/AqTxRJ4vusRBd3Jpqaqy7AecojL00lAQP0ORlQAvZ6Hj
KDhpJPIhV95qSLQTnOkkUF0JP+hafGC9iyBKmDfrDEI+zRYlaA/ARUe6sokBHKnO
Eashaih277N4sXq0YVjbAXZZrKJwK3uSyfkymwZjJFXY6dAa9w9PsfpQ2ck/doaK
BXsI9TOq7WwWOSLGkWm1OMeKBrtld26Doo8ukAhiQUANmTh3WNhgO1zK/KROFjOE
fqWJbubpiM6Rf+tl4nf4RcAV2pqfOO4atFk+YvtMxxLmQwPZ06OWwkypQzUxMOZb
yBSC5vEhZ6ODgT+jYMnghkzLD/FEm6UZLCU+xfGcb1iFOH6lNvXaw5/bxBfUnuuO
9+7wvw2TmZit6PAESj2msy3gS77JgaLOdrwk9GH3b4EZExLlqBTsY8n+HvfNL+qP
pkYlGl0SaWVnNlWYT3Y4pvLjs1MTrTZPUGD8sKz/6+YUdpyefIkuWVSjujEInOGx
EU9q8G4Zeg9GF4k7YaF3
=TdAU
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Chad Maniccia <CM...@mbgaustin.com>.
Oh and when I say it's not crashing, I just mean the JVM is not causing Tomcat to stop. It just seems to ignore the request instead.
Chad
________________________________________
From: Chad Maniccia <CM...@mbgaustin.com>
Sent: Friday, October 03, 2014 1:38 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
Hi Mark,
Thanks for replying. I actually reported this bug to Oracle before contacting this group. They contacted me once but then never replied again. I'd appreciate it if you could bring it to their attention again.
https://bugs.openjdk.java.net/browse/JDK-8058284
This bug is kind of elusive as a form that is crashing today might not crash tomorrow, I suspect it is because headers, cookies, session keys etc have changed. I'll see if I can reproduce it by creating a testing form.
Can anyone tell me why this line causes the site to not crash?
-XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
P.S.
Igal thanks for your support.
________________________________________
From: Mark Thomas <ma...@apache.org>
Sent: Friday, October 03, 2014 1:14 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
>> regardless of whose fault this is, Tomcat should be patched so that it
>> doesn't crash.
The general position of the Tomcat developers is that we do *not* patch
Tomcat to work around bugs in third party code.
There have been exceptions in the past but - since this JVM bug as a
workaround available - I very much doubt that Tomcat will be patched to
avoid this (even if such a patch was possible which looks unlikely).
> can you produce a reduced test case so that the good people at Tomcat
> can reproduce it on their end and patch it?
A reproducible test case is definitely a good thing but it needs to go
to Oracle, not to the Tomcat devs.
Note we do have some contacts with Oracle we can use to ensure a bug
report gets in front of the right people.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Chad Maniccia <CM...@mbgaustin.com>.
Hi Mark,
Thanks for replying. I actually reported this bug to Oracle before contacting this group. They contacted me once but then never replied again. I'd appreciate it if you could bring it to their attention again.
https://bugs.openjdk.java.net/browse/JDK-8058284
This bug is kind of elusive as a form that is crashing today might not crash tomorrow, I suspect it is because headers, cookies, session keys etc have changed. I'll see if I can reproduce it by creating a testing form.
Can anyone tell me why this line causes the site to not crash?
-XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
P.S.
Igal thanks for your support.
________________________________________
From: Mark Thomas <ma...@apache.org>
Sent: Friday, October 03, 2014 1:14 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
>> regardless of whose fault this is, Tomcat should be patched so that it
>> doesn't crash.
The general position of the Tomcat developers is that we do *not* patch
Tomcat to work around bugs in third party code.
There have been exceptions in the past but - since this JVM bug as a
workaround available - I very much doubt that Tomcat will be patched to
avoid this (even if such a patch was possible which looks unlikely).
> can you produce a reduced test case so that the good people at Tomcat
> can reproduce it on their end and patch it?
A reproducible test case is definitely a good thing but it needs to go
to Oracle, not to the Tomcat devs.
Note we do have some contacts with Oracle we can use to ensure a bug
report gets in front of the right people.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat JVM Crash
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Igal @ getRailo.org [mailto:igal@getrailo.org]
> Subject: Re: Tomcat JVM Crash
> fair enough, but first we need to ensure that this is not a Tomcat
> issue, right?
By definition, it *cannot* be a Tomcat problem. The JVM must not crash due to any bugs in pure Java code. (The JVM can be corrupted and thus crash if native libraries are involved, but that does not appear to be the case here.)
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by "Igal @ getRailo.org" <ig...@getrailo.org>.
On 10/3/2014 11:14 AM, Mark Thomas wrote:
> The general position of the Tomcat developers is that we do *not*
> patch Tomcat to work around bugs in third party code. There have been
> exceptions in the past but - since this JVM bug as a workaround
> available - I very much doubt that Tomcat will be patched to avoid
> this (even if such a patch was possible which looks unlikely).
fair enough, but first we need to ensure that this is not a Tomcat
issue, right? I agree that if it only happens with a certain browser
then it's unlikely that Tomcat is the issue, but TBH I'm concerned if
some hacker can drop my servers by issuing some planned https request.
> A reproducible test case is definitely a good thing but it needs to go
> to Oracle, not to the Tomcat devs. Note we do have some contacts with
> Oracle we can use to ensure a bug report gets in front of the right
> people. Mark
that would be sufficient because as long as this problem, if it does
exist, is resolved, then it doesn't matter to me (and I believe to other
users) who fixed it.
thanks,
Igal
--
Igal Sapir
Railo Core Developer
http://getRailo.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Mark Thomas <ma...@apache.org>.
On 03/10/2014 17:11, Igal @ getRailo.org wrote:
>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
>> regardless of whose fault this is, Tomcat should be patched so that it
>> doesn't crash.
The general position of the Tomcat developers is that we do *not* patch
Tomcat to work around bugs in third party code.
There have been exceptions in the past but - since this JVM bug as a
workaround available - I very much doubt that Tomcat will be patched to
avoid this (even if such a patch was possible which looks unlikely).
> can you produce a reduced test case so that the good people at Tomcat
> can reproduce it on their end and patch it?
A reproducible test case is definitely a good thing but it needs to go
to Oracle, not to the Tomcat devs.
Note we do have some contacts with Oracle we can use to ensure a bug
report gets in front of the right people.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by "Igal @ getRailo.org" <ig...@getrailo.org>.
> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
regardless of whose fault this is, Tomcat should be patched so that it
doesn't crash.
can you produce a reduced test case so that the good people at Tomcat
can reproduce it on their end and patch it?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Chad Maniccia <CM...@mbgaustin.com>.
Christopher,
I'll try turning off the APR next time I get a crashing form.
Thanks,
Chad
________________________________________
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Friday, October 03, 2014 2:01 PM
To: Tomcat Users List
Subject: Re: Tomcat JVM Crash
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jess,
On 10/3/14 2:46 PM, Jess Holle wrote:
> On 10/3/2014 1:11 PM, Mark Thomas wrote:
>> On 03/10/2014 17:07, Chad Maniccia wrote:
>>> Hi,
>>>
>>> I have discovered the source of the JVM crashes. I figured it
>>> best to share with the group because it is quite odd. I have
>>> tested this and confirmed with a colleague so as odd as it
>>> sounds it is reproducible.
>>>
>>> The crash is caused by a combination of Chrome web browser,
>>> HTTPS, and posting a form with an exact amount of data. If you
>>> use HTTP to submit the form=no crash, If you use IE and
>>> HTTPS=no crash. If you add/remove a single character to the
>>> form=no crash. I have attached the latest crash log. Please
>>> note that Tomcat crashes before it logs the request to
>>> "localhost_access_log" and before it passes the request to the
>>> servlet. This problem is present between multiple versions of
>>> Java and Tomcat.
>>>
>>> Here is another user reporting a similar issue.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8049855
>>>
>>> I did like they suggested and added the following line. This
>>> doesn't fix the problem but it prevents the server from
>>> crashing, you get a blank page instead. Why is this?
>>>
>>> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>>>
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or
>>> Oracle?
>> Oracle.
>>
>> Regardless of whether the input is valid or not it should not
>> trigger a JVM crash.
>
> Agreed.
>
> That said, one thing that really bothers me about including /any/
> native additional native libraries (ala JNI) in a Java process
> (but particularly a Java /server/ process) is that when the JVM
> experiences a native crash you cannot categorically blame the JVM
> vendor in this case.
>
> If you /don't/ have any additional native code, then you /can
> /categorically blame the JVM vendor -- clear and simple.
>
> This is one reason of several reasons that for me using APR in
> Tomcat is a non-starter.
>
> [Yes, you could always reproduce the issue with Java connectors,
> but that's painful and there are, of course, other reason for
> avoiding native libraries, e.g. having to build them across the
> numerous architectures one supports, rather than simple
> write-once-run-anywhere.]
The thread that evidently crashed the JVM was a NIO thread, but it's a
good catch that there were APR threads running as well.
Chad, can you disable the APR connector and still reproduce the
problem? Can you create a set of step-by-step instructions for
reproducing this problem so someone outside of your environment can
make it happen?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJULvKSAAoJEBzwKT+lPKRYx6YP/RGiKXeJmLwU9R+jdYP8OSFv
P5xYbMNsNQlGy9rHt9jSH1YH4fOGZRTGByoeLR9gno+9R3sFr5ABg8qXoQD/tqTS
RN9AYHgTjSrraNEG3/LOvHT7KlD+EpINo5iTHHWxFsyltra4k16VgdNX9ueVkAQM
ezE1HWorl6yMPFND/itgftqtQiik0ZPLu0UYGuAA0vbmdJgzYj1xFquP/4xy/0qD
T8WvHjWcWYUHouE3MJ3EGhh+kO1XdCRgLH8TvV2OQDvjPCo2pawpC2s816KEf7XM
xU/AbIDOxE9oM5ccJABEQywHMeC9n2FYwduFe0Ar42qsLIbaqRpUIF7yDRAjokW9
o092uzr626k+l4VlJdTWDH1I0h5DBa3kCkWehBbIAneGbo2arDbhNmtoBMwQCCBo
TKdRUSeeg7CbjpL2DavPLMZFeSSnp7wYnVMyIg9hRHj2X9gOSo/FjxzCfd7cBW+s
QkoSVR8Wc5mMylt4XED4BpzwxQb1HX2efSJkGC5Rqn4HXjekG7itbFrPveQ5n0ff
/D//Pb3OhxoD0E1Eh1ubb8QHi12LoJPFDIDQl4jQ0L2iaEvFQZOYdmyeOJwRQlvA
biXbUinIZPsYWH25QzzVOFsXhD2Oycjp9+XAjFJsuKn+hGpgViqYAEXq1xrU8KFh
jqhYIaRMyXVH3P//Xffo
=Rsxn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jess,
On 10/3/14 2:46 PM, Jess Holle wrote:
> On 10/3/2014 1:11 PM, Mark Thomas wrote:
>> On 03/10/2014 17:07, Chad Maniccia wrote:
>>> Hi,
>>>
>>> I have discovered the source of the JVM crashes. I figured it
>>> best to share with the group because it is quite odd. I have
>>> tested this and confirmed with a colleague so as odd as it
>>> sounds it is reproducible.
>>>
>>> The crash is caused by a combination of Chrome web browser,
>>> HTTPS, and posting a form with an exact amount of data. If you
>>> use HTTP to submit the form=no crash, If you use IE and
>>> HTTPS=no crash. If you add/remove a single character to the
>>> form=no crash. I have attached the latest crash log. Please
>>> note that Tomcat crashes before it logs the request to
>>> "localhost_access_log" and before it passes the request to the
>>> servlet. This problem is present between multiple versions of
>>> Java and Tomcat.
>>>
>>> Here is another user reporting a similar issue.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8049855
>>>
>>> I did like they suggested and added the following line. This
>>> doesn't fix the problem but it prevents the server from
>>> crashing, you get a blank page instead. Why is this?
>>>
>>> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>>>
>>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or
>>> Oracle?
>> Oracle.
>>
>> Regardless of whether the input is valid or not it should not
>> trigger a JVM crash.
>
> Agreed.
>
> That said, one thing that really bothers me about including /any/
> native additional native libraries (ala JNI) in a Java process
> (but particularly a Java /server/ process) is that when the JVM
> experiences a native crash you cannot categorically blame the JVM
> vendor in this case.
>
> If you /don't/ have any additional native code, then you /can
> /categorically blame the JVM vendor -- clear and simple.
>
> This is one reason of several reasons that for me using APR in
> Tomcat is a non-starter.
>
> [Yes, you could always reproduce the issue with Java connectors,
> but that's painful and there are, of course, other reason for
> avoiding native libraries, e.g. having to build them across the
> numerous architectures one supports, rather than simple
> write-once-run-anywhere.]
The thread that evidently crashed the JVM was a NIO thread, but it's a
good catch that there were APR threads running as well.
Chad, can you disable the APR connector and still reproduce the
problem? Can you create a set of step-by-step instructions for
reproducing this problem so someone outside of your environment can
make it happen?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJULvKSAAoJEBzwKT+lPKRYx6YP/RGiKXeJmLwU9R+jdYP8OSFv
P5xYbMNsNQlGy9rHt9jSH1YH4fOGZRTGByoeLR9gno+9R3sFr5ABg8qXoQD/tqTS
RN9AYHgTjSrraNEG3/LOvHT7KlD+EpINo5iTHHWxFsyltra4k16VgdNX9ueVkAQM
ezE1HWorl6yMPFND/itgftqtQiik0ZPLu0UYGuAA0vbmdJgzYj1xFquP/4xy/0qD
T8WvHjWcWYUHouE3MJ3EGhh+kO1XdCRgLH8TvV2OQDvjPCo2pawpC2s816KEf7XM
xU/AbIDOxE9oM5ccJABEQywHMeC9n2FYwduFe0Ar42qsLIbaqRpUIF7yDRAjokW9
o092uzr626k+l4VlJdTWDH1I0h5DBa3kCkWehBbIAneGbo2arDbhNmtoBMwQCCBo
TKdRUSeeg7CbjpL2DavPLMZFeSSnp7wYnVMyIg9hRHj2X9gOSo/FjxzCfd7cBW+s
QkoSVR8Wc5mMylt4XED4BpzwxQb1HX2efSJkGC5Rqn4HXjekG7itbFrPveQ5n0ff
/D//Pb3OhxoD0E1Eh1ubb8QHi12LoJPFDIDQl4jQ0L2iaEvFQZOYdmyeOJwRQlvA
biXbUinIZPsYWH25QzzVOFsXhD2Oycjp9+XAjFJsuKn+hGpgViqYAEXq1xrU8KFh
jqhYIaRMyXVH3P//Xffo
=Rsxn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat JVM Crash
Posted by Jess Holle <je...@ptc.com>.
On 10/3/2014 1:11 PM, Mark Thomas wrote:
> On 03/10/2014 17:07, Chad Maniccia wrote:
>> Hi,
>>
>> I have discovered the source of the JVM crashes. I figured it best to share with the group because it is quite odd. I have tested this and confirmed with a colleague so as odd as it sounds it is reproducible.
>>
>> The crash is caused by a combination of Chrome web browser, HTTPS, and posting a form with an exact amount of data. If you use HTTP to submit the form=no crash, If you use IE and HTTPS=no crash. If you add/remove a single character to the form=no crash. I have attached the latest crash log. Please note that Tomcat crashes before it logs the request to "localhost_access_log" and before it passes the request to the servlet. This problem is present between multiple versions of Java and Tomcat.
>>
>> Here is another user reporting a similar issue.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8049855
>>
>> I did like they suggested and added the following line. This doesn't fix the problem but it prevents the server from crashing, you get a blank page instead. Why is this?
>>
>> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>>
>> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
> Oracle.
>
> Regardless of whether the input is valid or not it should not trigger a
> JVM crash.
Agreed.
That said, one thing that really bothers me about including /any/ native
additional native libraries (ala JNI) in a Java process (but
particularly a Java /server/ process) is that when the JVM experiences a
native crash you cannot categorically blame the JVM vendor in this case.
If you /don't/ have any additional native code, then you /can
/categorically blame the JVM vendor -- clear and simple.
This is one reason of several reasons that for me using APR in Tomcat is
a non-starter.
[Yes, you could always reproduce the issue with Java connectors, but
that's painful and there are, of course, other reason for avoiding
native libraries, e.g. having to build them across the numerous
architectures one supports, rather than simple write-once-run-anywhere.]
--
Jess Holle
Re: Tomcat JVM Crash
Posted by Mark Thomas <ma...@apache.org>.
On 03/10/2014 17:07, Chad Maniccia wrote:
> Hi,
>
> I have discovered the source of the JVM crashes. I figured it best to share with the group because it is quite odd. I have tested this and confirmed with a colleague so as odd as it sounds it is reproducible.
>
> The crash is caused by a combination of Chrome web browser, HTTPS, and posting a form with an exact amount of data. If you use HTTP to submit the form=no crash, If you use IE and HTTPS=no crash. If you add/remove a single character to the form=no crash. I have attached the latest crash log. Please note that Tomcat crashes before it logs the request to "localhost_access_log" and before it passes the request to the servlet. This problem is present between multiple versions of Java and Tomcat.
>
> Here is another user reporting a similar issue.
>
> https://bugs.openjdk.java.net/browse/JDK-8049855
>
> I did like they suggested and added the following line. This doesn't fix the problem but it prevents the server from crashing, you get a blank page instead. Why is this?
>
> -XX:CompileCommand=exclude,com/sun/crypto/provider/*.*
>
> Whose problem is this: Google, Apache Tomcat, GoDaddy(SSL), or Oracle?
Oracle.
Regardless of whether the input is valid or not it should not trigger a
JVM crash.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org