RFR(XS): 8056930: Output host info under some condition for core dump
David Holmes
david.holmes at oracle.com
Tue Sep 9 04:57:06 UTC 2014
Hi Yumin,
Okay - thanks! We will see how this goes.
David
On 9/09/2014 2:52 PM, Yumin Qi wrote:
> David,
>
> I have done some test with following c++ code:
>
> #include "windows.h"
> #include "tchar.h"
> void StackOverflow(int depth)
> {
> char blockdata[10000];
> printf("Overflow: %d\n", depth);
> StackOverflow(depth+1);
> }
>
> int _tmain(int argc, _TCHAR* argv[])
> {
> for (;;)
> {
> __try
> {
> StackOverflow(0);
> }
> __except(EXCEPTION_EXECUTE_HANDLER)
> {
> LPBYTE lpPage;
> static SYSTEM_INFO si;
> static MEMORY_BASIC_INFORMATION mi;
> static DWORD dwOldProtect;
>
> _TCHAR buffer[1024];
> DWORD size = sizeof(buffer);
> if (GetComputerNameEx(ComputerNameDnsHostname, buffer,
> &size)) {
> printf("Computer Name: %s\n", buffer);
> } else {
> printf("Computer Name: N/A\n");
> }
> // Get page size of system
> GetSystemInfo(&si);
>
> // Find SP address
> _asm mov lpPage, esp;
>
> // Get allocation base of stack
> VirtualQuery(lpPage, &mi, sizeof(mi));
>
> // Go to page beyond current page
> lpPage = (LPBYTE)(mi.BaseAddress)-si.dwPageSize;
>
> // Free portion of stack just abandoned
> if (!VirtualFree(mi.AllocationBase,
> (LPBYTE)lpPage - (LPBYTE)mi.AllocationBase,
> MEM_DECOMMIT))
> {
> // If we get here, exit
> exit(1);
> }
>
> // Reintroduce the guard page
> if (!VirtualProtect(lpPage, si.dwPageSize,
> PAGE_GUARD | PAGE_READWRITE,
> &dwOldProtect))
> {
> exit(1);
> }
> printf("Exception handler %lX\n", _exception_code());
> Sleep(2000);
> }
> }
> return 0;
> }
>
> Tested on my PC (Windows 7), still can call GetComputerNameEx and return
> correct computer name.
> Under java stack overflow, we hit yellow pages. Which should be similar
> in this example.
>
> Thanks
> Yumin
>
> On 9/8/2014 4:41 PM, David Holmes wrote:
>> Hi Yumin,
>>
>> I'd overlooked the local buffer issue. Even a 1K buffer may be an
>> issue if the crash we are trying to report about related to
>> stackoverflow.
>>
>> David
>>
>> On 9/09/2014 6:35 AM, Yumin Qi wrote:
>>> Thanks for review again.
>>>
>>> Yumin
>>> On 9/8/2014 12:19 PM, Calvin Cheung wrote:
>>>> 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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
More information about the hotspot-runtime-dev
mailing list