On Dec 8, 2006, at 10:34 AM, Rob Lockstone wrote:
> Fwiw, I just restarted a server and got three of these SSL-related
> crashes in a row. It's just really, really bad when you try to
> restart a server and add it to a pool of active servers and it
> starts taking requests. Just awful.
So it sounds like there might be a startup synchronization issue.
Your previous case shows something similar.
> Again, I'd like to request that, at least for Windows, Caucho
> includes its own "we trust this build of OpenSSL DLL's for use with
> Resin". The constant crashing is painful to watch. And since I'm
> the "resin guy", even though I'm not a sysadmin, I get blamed when
> everything goes to pot. It's not fun. :-(
We can add the OpenSSL version we tested with. That's a good idea.
We can't distribute the dll itself.
I'll see if I can figure out how to reproduce it. It may be a bit
tricky to track down, though. Java's thread dumps are so much nicer.
> On Dec 8, 2006, at 09:10 , Scott Ferguson wrote:
>> On Dec 8, 2006, at 8:56 AM, Rob Lockstone wrote:
>>> Environment: Windows 2003 Server, Resin Pro 3.0.21, OpenSSL 0.9.8b,
>>> Java 1.4.2_12
>>> More information on what caused the JVM/Resin to spontaneously
>>> reboot. I get these fairly often (multiple times per month).
>>> They're not always the same exact thing. Often the stack trace
>>> references one of the SSL DLL's, but other times, like this one, it
>>> references the JVM DLL.
>>> In any event, since the "Java frames" section references some
>>> Caucho JNI calls, I'm sending this in. Scott, let me know if you
>>> want an official bug filed.
>> That would be great.
>>> I'm attaching two files to this email since the emailer likes to
>>> reformat stuff into unreadable chunks. One is the weird
>>> SSL_UNDEFINED_FUNCTION error I have never seen before and reported
>>> a few minutes. The other is the top portion of the JVM crash log
>>> where the jvm.dll was the source of the crash and Caucho JNI
>>> routines are being called.
>>> Btw, whenever the crash log mentions an SLL DLL as the source of
>>> the crash, the "Java frames" section is always something along
>>> these lines:
>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>> j com.caucho.vfs.JniStream.readNative(J[BII)I+0
>>> j com.caucho.vfs.JniStream.read([BII)I+43
>>> j com.caucho.vfs.ReadStream.readBuffer()Z+53
>>> j com.caucho.vfs.ReadStream.waitForRead()Z+12
>>> j com.caucho.server.port.TcpConnection.run()V+181
>>> j com.caucho.util.ThreadPool.runTasks()V+187
>>> j com.caucho.util.ThreadPool.run()V+85
>>> j java.lang.Thread.run()V+11
>>> v ~StubRoutines::call_stub
>>> Which is similar to the attached JVM DLL crash. What's up with
>>> com.caucho.vfs.JniStream.readNative ?
>> readNative itself should be solid. We've run it for days under very
>> heavy load (CPU load around 40 on multi-cpu systems) with no issues.
>> But there has been less time stressing openssl, so there might be
>> something odd there.
>> -- Scott
>>> resin-interest mailing list
>> resin-interest mailing list
> resin-interest mailing list
resin-interest mailing list