Debugging segmentation faults in the JVM on linux-powerpc

[Andrew Haley]

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
>> before
>>> spending more work on it. The coding in question is completely
>> architecture
>>> 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.
> 
> ..Thomas
> 
> 
>> --
>> Andrew Haley
>> Java Platform Lead Engineer
>> Red Hat UK Ltd. <https://www.redhat.com>
>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>>
> 


-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671