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

[Vicente Romero]

On 1/14/19 7:38 PM, Liam Miller-Cushon wrote:
> 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.

there is an early triage that could ask users for the file / parameters 
plus the release file which could also be helpful to reproduce the issue

>
> 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)?

I have modified the msg.bug to mention javac parameters too, see [1], 
this version also prints the parameters to the output in case of error

[1] http://cr.openjdk.java.net/~vromero/8216529/webrev.02/

Thanks,
Vicente

>
> On Mon, Jan 14, 2019 at 4:05 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto: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
>>>>>>     <mailto: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/
>>>>>>         <http://cr.openjdk.java.net/%7Evromero/8216529/webrev.00/>
>>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20190115/f9d610ee/attachment.html>