[PATCH] Improve Windows Minidump File Specification
David Holmes
david.holmes at oracle.com
Wed Jul 31 01:47:20 PDT 2013
On 31/07/2013 5:44 PM, Richard Fearn wrote:
>> It seems like you are asking for a similar piece of functionality as
>> Richard(cc:d) did:
>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2013-July/010390.html
>
> Yes, sounds very similar...
>
>> Since Windows is the only platform where we can decide on the file name of
>> the mdmp/core file it would be good if we could make this into a
>> platform-independent flag -XX:CrashFileDirectory or something to that
>> effect.
>>
>> Then we could change the code to create the hs_err_pid<num>.log in that
>> directory
>
> The location of that file (the fatal error log) can already be
> specified by -XX:ErrorFile, though.
>
>> and
>> * change the Windows code to create the mdmp in that directory
>> * change the *nix code to chdir(2) to the target directory before calling
>> abort(3)
>
> As an experiment, I added a -XX:CoreDumpDirectory option, and did the
> chdir quite early - before the fatal error log was written. This meant
> the fatal error log went into the CoreDumpDirectory, too, which I
> wasn't happy with, given the option name. However, if the option was
> called CrashFileDirectory, it would make more sense if the fatal error
> log were written into that directory as well.
>
> I moved the chdir later, but hit another problem: the fatal error log
> gives the current directory as a suggestion as to where the core dump
> can be found.
That of course would have to be updated as part of a patch to add a
specific dump location.
David
-----
If the current directory is changed later on, that will
> be incorrect. A nice side effect of allowing the fatal error log to go
> into the CrashFileDirectory would be that the current directory
> *could* be changed earlier (unless there's something else that would
> be affected by this, that I haven't spotted).
>
> I'd be happy to provide patches for the changes I've made, though I
> agree that it might be good to have a unified approach to this.
>
> Rich
>
More information about the hotspot-runtime-dev
mailing list