GC log corruption

[Kirk Pepperdine]

Hi Bernd,

ls -sk 100914-prd-6.1GA2-gc.log
40 100914-prd-6.1GA2-gc.log

So that is 40*4096 / 1024 = 160K…

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.

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.

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/ffbc5167/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/ffbc5167/signature.asc>