RFR: 8271003: hs_err improvement: handle CLASSPATH env setting longer than O_BUFLEN

Thomas Stüfe thomas.stuefe at gmail.com
Mon Aug 2 10:12:06 UTC 2021


On Mon, Aug 2, 2021 at 11:59 AM David Holmes <david.holmes at oracle.com>
wrote:

> On 2/08/2021 6:26 pm, Thomas Stuefe wrote:
> > On Mon, 2 Aug 2021 07:02:35 GMT, David Holmes <dholmes at openjdk.org>
> wrote:
> >
> >> `outputStream::do_vsnprintf` already states that it uses the buffer "if
> necessary". In the two highlighted cases there is no need to use the
> buffer, so I would argue that we should just modify the existing
> `outputStream::do_vsnprintf` logic to not truncate in these two cases as it
> is not necessary.
> >
> > I think we already do almost that.
> >
> >
> https://github.com/openjdk/jdk/blob/95f0fd6c4dfaea9c3e065485dd201decf2be98ba/src/hotspot/share/utilities/ostream.cpp#L94-L104
> >
> > Only thing, for print_cr() we still use the scratch buffer since we need
> to append \n. That could be done smarter.
>
> Right I missed that bit - but I guess we can do that as a separate
> write() call.
>
> > Beyond that, I think the O_BUFLEN thing is seriously annoying and I
> would like to have a better solution. One where we start with a
> preallocated buffer as we do now, but expand it dynamically (using raw
> ::malloc()) if necessary. That should still be reasonably safe.
>
> Raw malloc in the error handler is not safe if we're processing a
> signal. The malloc/signal deadlock is already seen with some of our
> abort tests.
>
>
I thought it would be a calculated risk. You only run into problems if
1) the output length is longer than the default static buffer, and we
allocate dynamically
2) we crash recursively in malloc or the C-heap is corrupted

Cheers, Thomas


> Cheers,
> David
>
> > -------------
> >
> > PR: https://git.openjdk.java.net/jdk/pull/4947
> >
>


More information about the hotspot-runtime-dev mailing list