GC log corruption

Kirk Pepperdine kirk at kodewerk.com
Tue Oct 14 11:02:16 UTC 2014


Hi Bernd,

Thanks for the response. This is the second file that I’ve seen come to me in this condition. However, this one is much worse than the other. As I mentioned before I didn’t have specific details about the first one. I’m not speaking to the source of the second one to confirm bits of information. For one they are not using file rotation. I’ve asked for the ls -sk to see if the file is sparse. One more bit of information, the JVM is running virtualized with NAS so it could be this is the source of the corruption. All I can say is that in the 1000s of GC logs I’ve got only 2 display this problem so I’d give it a low probability that it’s in the JVM. That said, these two are recent occurrences so I thought I’d ask just in case it’s a more common occurrence.

Kind regards,
Kirk

On Oct 13, 2014, at 7:30 PM, Bernd <ecki at zusammenkunft.net> wrote:

> 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.
> 
> 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).
> 
> 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?
> 
> 2014-10-10 21:42 GMT+02:00 Kirk Pepperdine <kirk at kodewerk.com>:
> Hi,
> 
> 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.
> 
> 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.
> 
> Kind regards,
> Kirk Pepperdine
> 
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20141014/06317eec/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20141014/06317eec/signature.asc>


More information about the hotspot-gc-dev mailing list