RFR : 8211326 : add OS user related information to hs_err file

[Baesken, Matthias]

Hi Thomas , looking forward to the  CSR , I think  we can use then the flags introduced in the CSR  in  8211326  .

Best regards, Matthias


> -----Original Message-----
> From: Thomas Stüfe <thomas.stuefe at gmail.com>
> Sent: Donnerstag, 4. Oktober 2018 20:11
> To: David Holmes <david.holmes at oracle.com>
> Cc: Baesken, Matthias <matthias.baesken at sap.com>; HotSpot Open Source
> Developers <hotspot-dev at openjdk.java.net>
> Subject: Re: RFR : 8211326 : add OS user related information to hs_err file
> 
> On Thu, Oct 4, 2018 at 11:18 AM David Holmes <david.holmes at oracle.com>
> wrote:
> >
> > Hi Thomas,
> >
> > On 4/10/2018 6:27 PM, Thomas Stüfe wrote:
> > > Hi David,
> > > On Thu, Oct 4, 2018 at 9:44 AM David Holmes
> <david.holmes at oracle.com> wrote:
> > >>
> > >> Hi Matthias,
> > >>
> > >> I'm hoping others will chime in here as I:
> > >>
> > >> a) don't know if this information is actually useful for an error log of
> > >> this kind;
> > >>
> > >> b) don't know if the information might be considered sensitive or not;
> and
> > >>
> > >
> > > I have no opinion on (a) and (b).
> >
> > That's a shame :)
> >
> > >> c) don't think it's worth the effort of adding a flag to control this.
> > >> Plus the flag is only useful for trying to reproduce an issue; if it's a
> > >> one-of failure then you've already missed out on the information in the
> > >> log file.
> > >
> > > How about a more generic switch to control verbosity of the error report?
> > >
> > > The way we and you use the error files seem to differ. You seem to
> > > prefer them short and snappy and bare any security relevant details
> > > (as far as that is even possible in an hs-err file). As was once
> > > mentioned in a similar discussion, "OpenJDK hs-err files get posted
> > > verbatim in forums and bug reports".
> > >
> > > We use the hs-err files differently. They are usually handed down to
> > > us by our customers thru secure channels, and for us size does not
> > > matter much, nor does security relevant information since we have
> > > contracts with our customers.
> >
> > To be honest I don't deal with hs-err files from other people very much
> > at all. But from what I have dealt with I haven't, to the best of my
> > recollection, encountered any crash investigation where all this extra
> > info would have shed any light. But most crashes I investigate are
> > developer related rather than end user.
> 
> That may be the difference.
> 
> We get crash reports from customers, often with little context, no
> repros, no cores, nothing. So we have to make do with what we have,
> which is the hs-err files. Therefore we make them as extensive as
> possible. Our support worked miracles with just these files. It is
> incredible what you can deduce from them.
> 
> User information, e.g., can hint towards a mismanaged installation, if
> the server node does not run under the correct user. I also dimly
> remember it being useful in analyzing SIGBUS crashes for mapped files
> on Solaris.
> 
> So, it turns out I have an opinion :) Well when I say no opinion I
> mean I can see arguments for both sides, and I feel uncomfortable
> pressing our way of working upon the OpenJDK code base.
> 
> >
> > > That has been a point of contention over and over again in the past.
> > > So I wonder whether one, or possibly two, general switches could keep
> > > both sides happy. Something like -XX:+ExtendedErrorReports" and
> > > possibly "-XX:+ErrorReportsIncludeSensitiveData".
> > >
> > > Those switches could be, by default, false in the OpenJDK.
> > >
> > > Any additions we add to error reporting where we cannot find an
> > > agreement we could make conditional on one or the other switch.
> > >
> > > What do you think?
> >
> > Seems reasonable to propose. Any new flag will require a CSR request.
> >
> 
> Okay, thanks!
> 
> I will file a CSR next week when I am back at the office.
> 
> ..Thomas
>