Debugging segmentation faults in the JVM on linux-powerpc
aph at redhat.com
Mon Jun 12 13:23:24 UTC 2017
On 12/06/17 14:15, Thomas Stüfe wrote:
> On Mon, Jun 12, 2017 at 2:22 PM, Andrew Haley <aph at redhat.com> wrote:
>> On 12/06/17 13:08, Thomas Stüfe wrote:
>>> I agree with Severin. It makes sense to rule out a compiler failure
>>> spending more work on it. The coding in question is completely
>>> independent, and the fact that it only happens on one platform, and that
>>> the error vanishes in slowdebug, is suspicious.
>> Not necessarily. The problem seems to be that we get a failure when
>> allocating a direct byte bufer, in Bits.reserveMemory(). The limit is
>> controlled by -XX:MaxDirectMemorySize.
>> It might well be a bug in the Zero interpreter. I'd start by adding a
>> couple of lines in Bits.tryReserveMemory() to print out the
>> totalCapacity when allocation fails.
> I think there are several problems. The original problem, the bytebuffer
> OOM, happens in his release build. He then did a debug build. Slowdebug
> worked (?) but fastdebug crashed very early in SafeFetch initialization in
> tests which are omitted in release build.
Ignore the SafeFetch problem; it's something else.
Let's concentrate on one thing at at a time.
> So, multiple problems in optimized code.
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-dev