RFR(trivial): 8231024: Improve the debug info when the output is truncated
david.holmes at oracle.com
Mon Sep 16 07:44:35 UTC 2019
On 16/09/2019 5:09 pm, Jie Fu wrote:
> Hi David,
> Sorry for the confusion.
The confusion is mine, not from you :)
> On 2019/9/16 下午2:40, David Holmes wrote:
>> Okay I'm confused. I had assumed that the passed in buffer size must
>> be different in each case because of the 2014/2032/2050 values in the
>> message, but in fact they are all sized at 2000.
> According to the source code, the buffer size can be either
> 2000(O_BUFLEN)  or 2048(BUFLEN) .
> So it isn't always 2000.
It is 2000 is all three examples of the output that you gave.
>> That makes no sense
> I think it makes sense.
> It is still unclear which one (O_BUFLEN or BUFLEN?) should be increased
> if the current buffer size wasn't printed.
You need to know the original caller that passed in the buffer size.
But we can't just keep increasing the buffer size. We probably need to
examine the callers to see what amount of information is trying to be
passed through. Then decide whether to adjust what the callers are
passing through, or adjust the buffer size - perhaps on a callsite by
callsite basis rather than just bumping O_BUFLEN or BUFLEN.
>> - how can we have written e.g. 2014 bytes to a buffer of only 2000 bytes?
> The output is truncated since the current buffer size is too small
> (e.g., 2000 < 2014).
Ah sorry - I'd missed that aspect of vsnprintf. We're calling:
102 int written = os::vsnprintf(buffer, buflen, format, ap);
but it isn't "written" when it exceeds buflen, it's the required buffer
>> Do we have a bug in os::vsnprintf?
> I don't think so.
> Thanks a lot.
> Best regards,
More information about the hotspot-dev