GC log corruption

[Bernd]

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/20141013/9e2bbb10/attachment.htm>