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

Tue Jan 15 19:07:53 UTC 2019

Hi Liam,

What do you think about the last version? I propose to start with this 
approach and modify it going forward as we get more feedback from users

Thanks,
Vicente

On 1/15/19 8:47 AM, Vicente Romero wrote:
>
>
> 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/bc9429ff/attachment-0001.html>