<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>