RFR(S): 8074354: tests that intentionally crash the VM can timeout creating a core file

[Thomas Stüfe]

Hi Staffan,

you mean the ability to switch between full and partial dumps on windows?

Sure, I can do that :)

Of course, you would have to add a windows-only switch in addition to
Yumins 'CreateCoredumpOnCrash', something like "MiniDumpType=full/partial"
or similar, and I can see people objecting because it adds complexity.

Also, I think we are quite OT by now. We should move these discussions
(about order of dumping and whether to allow partial dumps on windows) to a
new thread.

Thomas





On Thu, Mar 12, 2015 at 8:33 AM, Staffan Larsen <staffan.larsen at oracle.com>
wrote:

>
> On 11 mar 2015, at 20:58, Thomas Stüfe <thomas.stuefe at gmail.com> wrote:
>
> Hi Staffan,
>
> As in Staffan L's comments, we need to have a discuss and make final
>> decision for it --- tradeoff.
>>
>>
>> Given that core files on other platforms are useful even after we write
>> the hotspot error logs, it would probably make sense to have the same
>> mechanism on all platforms as Thomas points out. I haven’t been debugging
>> many windows failures lately so perhaps someone who does can chime in here?
>>
>> Personally I prefer a full dump when VM crashes on Windows, which is more
>> helpful. I found minidump not very helpful in most of the cases.
>>
>>
>> Windows calls all crash dumps “minidumps”. They can however be configured
>> to include more or less information, but even with all the information it
>> is still called a “minidump” (or at least the API for creating them is
>> called that).
>>
>>
> Sorry, my sentence was garbled and not very clear.
>
> I was referring to the MINIDUMP_TYPE parameter on MiniDumpWriteDump(): in
> our code base, we used to have a switch to write either full minidumps
> (with MiniDumpWithFullMemory set) or partial minidumps without full memory
> info, just the thread stacks. Trade off was minidump size: full memory info
> made for very large dumps, the partial ones were small.
>
> In practice we found the full dumps often too large and unwieldy, and the
> partial ones were often useless. So in the end we came to rely on the error
> logs and put lots of work into improving those.
>
>
> That sounds great - something you are planning to contribute?
>
> /Staffan
>
>
> Thomas
>
>
>
>> /Staffan
>>
>>
>>
>
>