<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Bernd,<div><br></div><div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: red;">ls -sk 100914-prd-6.1GA2-gc.log<o:p></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: red;">40 100914-prd-6.1GA2-gc.log</span></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif;"><br></div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;">So that is 40*4096 / 1024 = 160K…</div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;"><br></div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;">Apparently the log corrupts if you kill the JVM when it’s run out of memory. Looks like the problem maybe reproducible as it’s happened again. The log was in perfect shape and then the unresponsive JVM was killed and then the log was corrupted. Best answer is to not have the JVM OOME but that’s a different story. Sounds like a problem with buffers being flushed prior to the file handle being closed/recycled by the OS.</div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;"><br></div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;">Unless this rings a bell I’m not going to spam the mailing list with more details about this problem unless I can confirm that it’s really the JVM at fault. At the moment it sound like a problem with the OS/Virtualization/hardware.</div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;"><br></div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;">Regards,</div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;">Kirk</div><div style="margin: 0in 0in 0.0001pt; font-size: 15px; font-family: 'Times New Roman', serif;"><br></div><div><div>On Oct 13, 2014, at 7:30 PM, Bernd <<a href="mailto:ecki@zusammenkunft.net">ecki@zusammenkunft.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hmm... null-bytes in a logfile typically mean a hardware or os crash (with a filesystem which does increase meta-data length attribute before flushing the data). However in your case ths looks unlikely, cause the data after the null bytes is older timestamps and there are quite a few null bytes.<br><br>So besides a real problem inside the tracing code (never seen that) one other option might be that there has been a rename/truncation going on and that the JVM was seeking to its current position (creating a hole).<br><br>Can you check with "ls -sk" if the file is sparse (which would point in that direction). Do you use log rotation (JVM or external) on those files?<br></div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-10 21:42 GMT+02:00 Kirk Pepperdine <span dir="ltr"><<a href="mailto:kirk@kodewerk.com" target="_blank">kirk@kodewerk.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I’ve run into this only once before and only just recently. I didn’t report it the first time because I was unable to get any details and I thought it might be an aberration so… but this time I’ve got or can get any details needed.<br>
<br>
I’ve attached the log produced by a 170_25 JVM running in RHL. The JVM ran out of heap and this is the log that was sent. As you can see it looks as if the middle of the file was over-written by a zero’ed out buffer. Just curious if anyone has reported this or if I need to fill out a bug report.<br>
<br>
Kind regards,<br>
Kirk Pepperdine<br>
<br>
<br><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></body></html>