https://bz.apache.org/bugzilla/show_bug.cgi?id=62626
--- Comment #12 from Christopher Schultz <ch...@christopherschultz.net> --- (In reply to jan.pfeifer from comment #11) > (In reply to Christopher Schultz from comment #10) > > Have a look at this page: > > https://wiki.apache.org/tomcat/FAQ/KnownIssues#ImageIOIssues > > If I undestand correctly there is only problem when using ImageIO.write with > response output stream. I do not use it that way. I write with ImageIO to > filesystem. Then, when image is ready, I read it again and write it to > response stream via Buffered IN/Out stream. Hmm, yes, this was in cases where ImageIO was being used to write to the servlet output stream. So it looks like that isn't the problem. > > Try going back up to Java 10 and wrapping your streaming-ImageIO uses in the > > class shown in that wiki page and re-running. If the crashes stop, we can go > > ahead and blame them on ImageIO, but really tcnative should not crash in > > this scenario... I'd expect that you'd just get lots of IOExceptions > > instead. So tcnative isn't doing its job under this circumstance. > > I left if for weekend with Java 8 to see what happens. Yes there are many > IOExceptions already. No crash so far. Just to confirm: this is Java 8 with APR+OpenSSL, not NIO+OpenSSL, correct? If that's the case, there might be some kind of incompatibility between tcnative and Java 9. That would be very surprising to me, but that seems to be where the data are leading us. > > Unfortunately, I don't have win32 debugging environment available to me, so > > I'm not able to turn the 0xe6fc9 offset into a meaningful line of code to > > investigate. It's obviously somewhere in the tcnative implementation of > > SSLSocket.handshake (or something it calls). That function has ~100 lines of > > code in it, but I'm guessing it's crashing towards the beginning, probably > > on a read. > > > > Can you use a DEBUG build of tcnative to get a better crash report? I'm used > > to seeing more of a stack trace in native crash dumps. > > I will try to get DEBUG build on monday. But there is a lot of other debug > info already. As I posted earlier i can attach it. Tomcat generated very > long bug report from which i posted the top part and sysinfo part, and > several gigs big mdmp file. Do you want to see them or we stick to DEBUG > build of tcnative plan? The Java stack traces are less important than the native stack trace. There was only a single item in the native stack trace you already posted. Can you post the part of the native report that is labelled "------ T H R E A D -------"? That should include a lot more relevant information. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
