RFR(s): 8148425: strerror() function is not thread-safe

[Thomas Stüfe]

Hi Volker,

On Fri, Feb 26, 2016 at 8:00 PM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi Thomas,
>
> it's good that somebody finally addresses this long standing issue :)
>
>
 Thanks :)


> However I wonder if it would be possible to align this effort with the
> core libraries group (CC'ed). They already fix this issue with:
>
> 8133249: Occasional SIGSEGV: non thread-safe use of strerr in
> getLastErrorString
> https://bugs.openjdk.java.net/browse/JDK-8133249
>
> I would be nice if we could use the same version in hotspot and the
> core libraries.
>
>
David already gave a good answer to this. For details see the comments in
the bug report.

In addition, there is the localization strerror(_s) provides: it is useless
and actually counterproductive in log files intended for the VM developers
themselves; but if those error messages get stuffed into Java Exception
texts and presented to the user, they might make more sense.

Kind Regards, Thomas


> Regards,
> Volker
>
>
> On Fri, Feb 26, 2016 at 5:05 PM, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> > Hi,
> >
> > please take a look at this proposed fix:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8148425
> > Webrev:
> >
> http://cr.openjdk.java.net/~stuefe/webrevs/8141425-strerror-replacement/webrev.00/webrev/
> >
> > This adds a replacement function os::strerror() as a drop-in for
> > strerror(), which has a number of issues.
> >
> > strerror() is unsafe to use and may cause (and has caused) crashes in
> > multithreaded scenarios. It is also not ideal for log files because of
> the
> > implicit localization of the error messages.
> >
> > For details please see the discussion under the bug report.
> >
> > Please note that I did not yet change any call sites, although all call
> > sites in the os namespace should already use the new function. I wanted
> to
> > see whether there would be any general objections.
> >
> > Kind Regards, Thomas
>