[13] RFR(S): 8223885: hs_err and replay file may contain garbage when overwriting existing file

[Thomas Stüfe]

Again, sorry for that.

I found that CDT (I use Eclipse CDT) call hierarchy was lying to me and did
not show the second call to prepate_log_file in VMError::report_and_die(),
so I missed the fact that this affects compiler replay files. I am upset by
this, since CDT is my main work tool nowadays.

Also confusing is that the submit tests went thru fine. So I guess the
replay compiler test is not part of the submit test suite.

I will redo this fix.

..Thomas

On Thu, May 16, 2019 at 4:21 AM David Holmes <david.holmes at oracle.com>
wrote:

> Hi Tobias,
>
> Thinking more on this problem I think we need to back out JDK-8221738
> and redo it so that it only affects the error file. It was never
> discussed that it would also impact the replay file, and such a change
> was not part of the CSR. I will file a bug for that.
>
> But I'm also a bit perplexed about the current bug and how it arose. The
> issue is that we overwrote an existing replay file with a shorter
> version and so got garbage at the end. When that file was read back the
> garbage caused the problem. But how did we come to write a replay file
> that already existed? Was this not named in a process-unique way?
> Further, before the change by JDK-8221738 the fact the file existed
> meant we would have written it to a different location - in which case
> how would the code that ends up reading the file know to get it from the
> other location given it would have found the old file in the original
> location?
>
> Thanks,
> David
> -----
>
> On 15/05/2019 8:15 pm, Tobias Hartmann wrote:
> > Thanks David!
> >
> > Best regards,
> > Tobias
> >
> > On 15.05.19 11:53, David Holmes wrote:
> >> Looks good! Thanks for recognising the problem. Always some unintended
> consequence to every fix :(
> >>
> >> Cheers,
> >> David
> >>
> >> On 15/05/2019 7:23 pm, Tobias Hartmann wrote:
> >>> Hi,
> >>>
> >>> please review the following patch:
> >>> https://bugs.openjdk.java.net/browse/JDK-8223885
> >>> http://cr.openjdk.java.net/~thartmann/8223885/webrev.00/
> >>>
> >>> With the fix for JDK-8221738 we now overwrite existing hs_err and
> replay files without truncating
> >>> the file. This may lead to garbage at the end of the file if the newly
> written data requires less
> >>> space. Similar to ciEnv::dump_replay_data() and
> ciEnv::dump_inline_data(), we should open the file
> >>> with O_TRUNC to ensure it's properly truncated to zero size.
> >>>
> >>> Thanks,
> >>> Tobias
> >>>
>