RFR: JDK-8216529: in case of a crash, javac should print out the parameters passed to it

[Liam Miller-Cushon]

My concern was mostly that users might forget to include the separate file
in their report, and by the time it's triaged it's probably too late to get
that information.

Making it easy to copy-paste the arguments as part of the crash message
could help, but I understand the concern about console spam. If you were to
print a subset, the non-file options are probably the most interesting
(especially non-standard options, as in e.g. JDK-8059453).

But having the full list of arguments is even better. Maybe add a reminder
to the diagnostic text to include the params file when reporting a bug
(possibly in the "Include your program and the following diagnostic" part
of msg.bug)?

On Mon, Jan 14, 2019 at 4:05 PM Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

>
>
> On 01/14/2019 02:59 PM, Vicente Romero wrote:
>
>
>
> On 1/14/19 4:20 PM, Jonathan Gibbons wrote:
>
> Do you mean the trimming done by jtreg?   That will obviously only happen
> if the crash happens in the context of a test.
>
>
> no I saw that issue for bugs breaking the JDK build and I saw that the
> output was incomplete
>
>
> It's still the case that what you describe is our internal infrastructure
> trimming the output, and most users will not suffer the same restrictions.
>
>
>
> As a general solution, if you can't write the file, you could write the
> non-file options, and the first N files, to the console, for some suitable
> N. That being said, if you're just printing argv, you don't easily have the
> analysis of file vs non-file options, so it may just come down to print the
> first N args, for a different, bigger N.
>
>
> I tend to believe that the general case in which this will be most useful
> will be cases with a large number of parameters, so I tend to think that it
> should be better to generate no output rather than generate an incomplete
> output. But I could be convinced otherwise :)
>
>
> Maybe. "No output" means no way of guessing what the input was;  "Some
> output" means you might at least show enough to show all the options, even
> if you don't show all the files.  But either way, if you fail to write the
> output, you should report that to the console, so that folk who are
> expecting to see the output and not surprised when it is not generated.
>
>
>
> -- Jon
>
>
> Vicente
>
>
>
>
> On 01/14/2019 12:03 PM, Vicente Romero wrote:
>
> Hi Liam,
>
> On 1/14/19 2:38 PM, Jonathan Gibbons wrote:
>
> The intent is the crash report should contain the path of the file, and
> the file should be in "@-file" format, to make it easier to rerun the
> compilation using the file with `javac @javac.<date>.args`.   If an error
> occurs when writing to the file, the info could be written to the console,
> but note that there could be a huge amount of output, depending how many
> files are specified on the command-line.
>
>
> right, what Jon says. I decided not to write to the console because if the
> output is huge, most of it will be lost as it will be trimmed thus reducing
> the usefulness of it.
>
> -- Jon
>
>
> Vicente
>
> On 1/14/19 11:22 AM, Liam Miller-Cushon wrote:
>
> Hi Vicente,
>
> This looks useful.
>
> Did you consider printing the args to stderr instead of writing them to a
> file, maybe as part of msg.bug? If I'm reading the patch correctly it
> currently uses a file `javac.<date>.args` in the directory javac is running
> from, which users won't necessarily know about to include in crash reports,
> and which won't succeed if javac doesn't have permissions to create files
> in the working directory.
>
> On Mon, Jan 14, 2019 at 10:51 AM Vicente Romero <vicente.romero at oracle.com>
> wrote:
>
>> Please review the fix for enhancement [1] at [2]. The idea of this
>> enhancement is to print out to a file the arguments passed to javac is
>> there is a fatal error or if a hidden option is passed to the compiler.
>> This could be very helpful to reproduce some bugs reported by users.
>>
>> Thanks,
>> Vicente
>>
>> PS, thanks to Jon for offline feedback an suggestions
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8216529
>> [2] http://cr.openjdk.java.net/~vromero/8216529/webrev.00/
>>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190114/6aa548d0/attachment.html>