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

[Jonathan Gibbons]

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/20190114/557452e7/attachment-0001.html>