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

David Holmes david.holmes at oracle.com
Thu Dec 1 13:23:29 UTC 2016


Hi Volker,

On 1/12/2016 8:35 PM, Volker Simonis 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.

Seems reasonable - though I don't know the C++ alignment rules for 
static unions to know whether this is guaranteed to be correct, or just 
very likely to be correct.

I'm also wondering if anyone knows exactly why only the Solaris 
slowdebug build detected the problem?

Thanks,
David

> Thank you and best regards,
> Volker
>


More information about the hotspot-runtime-dev mailing list