RFR(S): 8170548: VM may crash at startup because StdoutLog/StderrLog logging stream can be badly aligned

Thomas Stüfe thomas.stuefe at gmail.com
Thu Dec 1 10:50:27 UTC 2016


This is a good catch!

I wonder why we could not just call the normal new() instead of placement
new in LogFileStreamInitializer()? Is it because LogStdoutOutput is derived
from CHeapObj, and we do not yet want to call os::malloc() ?

Thanks, Thomas


On Thu, Dec 1, 2016 at 11:35 AM, Volker Simonis <volker.simonis at gmail.com>
wrote:

> Hi,
>
> can I please have a review and sponsor for the following fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8170548/
> https://bugs.openjdk.java.net/browse/JDK-8170548
>
> Change "8146009: "pure virtual method called" with using new GC
> logging mechanism" introduced a sophisticated initialization mechanism
> for the logging stream. In order to avoid deconstruction of the
> streams before the VM exits, it creates them with a placement new into
> statically allocated memory:
>
> static bool initialized;
> static char stdoutmem[sizeof(LogStdoutOutput)];
> static char stderrmem[sizeof(LogStderrOutput)];
>
> LogStdoutOutput &StdoutLog = reinterpret_cast<
> LogStdoutOutput&>(stdoutmem);
> LogStderrOutput &StderrLog = reinterpret_cast<
> LogStderrOutput&>(stderrmem);
>
> LogFileStreamInitializer::LogFileStreamInitializer() {
>   if (!initialized) {
>     ::new (&StdoutLog) LogStdoutOutput();
>     ::new (&StderrLog) LogStderrOutput();
>     initialized = true;
>   }
> }
>
> Unfortunately it is not guaranteed, that the static memory (which is a
> char array) is well-aligned for the stream objects. Actually, the C++
> standard only defines that it has to be at least 'char' aligned which
> is obviously not enough for a stream object.
> When building 'slowdebug' on Solaris with SS12u4 we indeed observed
> reproducible crashes during VM initialization because of this issue.
>
> The fix is easy - just wrap the character arrays into unions to align
> them appropriately.
>
> Thank you and best regards,
> Volker
>


More information about the hotspot-runtime-dev mailing list