RFR: 8269886: Inaccurate error message for compressed hprof test

David Holmes david.holmes at oracle.com
Tue Jul 6 04:12:09 UTC 2021


Hi Lin,

On 6/07/2021 1:33 pm, Lin Zang wrote:
> On Tue, 6 Jul 2021 02:55:37 GMT, Lin Zang <lzang at openjdk.org> wrote:
> 
>> The current implementation of hprof Reader for testing always prompts "Can not decompress the compressed hprof file" when there is error for testing gzipped heap dump. This is inaccurate if the gzipped file was decompressed successfully but the hprof file format is incorrect. So the inaccurate error message could be misleading for issue analysis.
>>
>> This trivial PR refine the error message by simply print "Can not get stack trace from the compressed hprof file", the underlying exception from GZIPInputStream() or HprofReader() would give accurate error info.
> 
> Hi David,
>      Thanks for review and comments.
> 
>> The existing message is a generic message covering the general operation of the whole try block. It seems far more appropriate than your new message, which only seems to apply to the final step. ???
> 
> IMO, the whole method named getStack() is used to get the stack trace for the hprof file.  And the try block could throw exceptions by serveral reasons as decribed, so IMHO printing "Can not decompress the compressed hprof file" is not accurate. The proposed change is to print a generic error message that the getStack() fail when processing compressed hprof.  And the extra 'e' argument in the changed line would give detailed reason.
> 
> So may be change error message to "Can not process the compressed hprof file" is better? what do you think?

Yes that seems a good middle ground.

Alternatively, but more effort, have different try/catch blocks for the 
two sections of the code. The first to decompress and write out; the 
second to extract the stack traces. It isn't obvious that exceptions are 
possible from both parts.

Thanks,
David

> BRs,
> Lin
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/4685
> 


More information about the serviceability-dev mailing list