RFR(XS): 8056930: Output host info under some condition for core dump

[Calvin Cheung]

On 9/8/2014 11:43 AM, Yumin Qi wrote:
> Calvin,
>
>   Thanks for the review, yes, it is webrev01 (now updated with buffer 
> len to 1024, see below).
>
> /lpBuffer/[out]
>
>     A pointer to a buffer that receives the computer name or the
>     cluster virtual server name.
>
>     The length of the name may be greater than MAX_COMPUTERNAME_LENGTH
>     characters because DNS allows longer names. To ensure that this
>     buffer is large enough, set this parameter to*NULL*and use the
>     required buffer size returned in the/lpnSize/parameter.
>
> /lpnSize/[in, out]
>
>     On input, specifies the size of the buffer, in*TCHARs*. On output,
>     receives the number of*TCHARs*copied to the destination buffer,
>     not including the terminating*null*character.
>
>     If the buffer is too small, the function fails and*GetLastError*
>     <http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360%28v=vs.85%29.aspx>returns
>     ERROR_MORE_DATA. This parameter receives the size of the buffer
>     required, including the terminating*null*character.
>
>     If/lpBuffer/is*NULL*, this parameter must be zero.
>
> In winbase.h:
>
> #ifndef _MAC
> #define MAX_COMPUTERNAME_LENGTH 15
> #else
> #define MAX_COMPUTERNAME_LENGTH 31
> #endif
>
> So it is 15 in most case, but it is not enough for most cases in 
> network name, I put 4K here think that is enough for most of the cases.
The length of 15 is for the NetBios name. In this case, we want to get 
the DNS host name. That's why 15 won't be sufficient.

> According to the description, I set buffer = NULL, and size to 0, the 
> call failed.
Yes, the call should fail with the return code of ERROR_MORE_DATA and 
the third parameter ( _Inout_  LPDWORD lpnSize) will contain the number 
of bytes required to receive the name. This way, the caller can 
dynamically allocate a buffer large enough for the name.
>
> I updated again, and set the buffer len as 1K, 1024 bytes, which I 
> think should be enough.
Yes, I think it's large enough for this fix.

Calvin
> The specs in MSDN are confusing some time and not consistent in their 
> pages.
>
> Thanks
> Yumin
>
>
>
>
> On 9/8/2014 10:29 AM, Calvin Cheung wrote:
>> Yumin,
>>
>> os_windows.cpp
>>
>> 1592   char buffer[4096];
>>
>> Why do you need a 4k buffer?
>>
>> According to: 
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724220(v=vs.85).aspx
>> "Each name can be up to 255 bytes total. "
>>
>> So maybe 256 is sufficient?
>>
>> btw, is your new webrev located at: 
>> http://cr.openjdk.java.net/~minqi/8056930/webrev01/ ?
>>
>> thanks,
>> Calvin
>>
>> On 9/8/2014 10:17 AM, Yumin Qi wrote:
>>> Hi,
>>>
>>>   I made a small change to Windows part, when GetComputerNameEx 
>>> fails, instead of do nothing, output "N/A".
>>>
>>> Thanks
>>> Yumin
>>>
>>> On 9/5/2014 2:46 PM, Yumin Qi wrote:
>>>> Please review
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8056930
>>>> Webrev: http://cr.openjdk.java.net/~minqi/8056930/webrev00
>>>>
>>>>   After java crashed, we would like to know the host on which it 
>>>> failed especially when doing parallel testing on multiple machines. 
>>>> The most useful for knowing host name is telling if the test is 
>>>> hardware related, that the test can only repeat on it. This piece 
>>>> of code help to print out host name in debug mode.
>>>>
>>>>   Test: manually tested on Unix/Linux/Windows with 
>>>> -XX:+CrashGCForDumpingJavaThread.
>>>>    JPRT
>>>>
>>>> Thanks
>>>> Yumin
>>>
>>
>