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

[David Holmes]

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