Java fatal error SIGSEGV with no added native code
Asked Answered
N

1

15

I am getting an error message from the Java compiler that I don't understand. I've tested my code on OSX 10.6, 10.9, and Ubuntu 14.04, with both Java 6 and 7. When I run with the Eclipse debugger or from the interpreter (using -Xint option), everything runs fine. Otherwise, I get the following messages:

Java 1.6:

Invalid memory access of location 0x8 rip=0x1024e9660

Java 1.7:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010f7a8262, pid=20344, tid=18179
#
# JRE version: Java(TM) SE Runtime Environment (7.0_60-b19) (build 1.7.0_60-b19)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.60-b09 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# V  [libjvm.dylib+0x3a8262]  PhaseIdealLoop::idom_no_update(Node*) const+0x12
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

There's more error output for Java 7 (that is saved to a file) but unfortunately I can't fit it in the character limit of this post. Sometimes I need to run my code a couple of times for the error to come up, but it appears more often than not.

My test case involves cacheing some computations in logarithmic scale. Specifically, given log(X),log(Y),..., I have a small class that computes log(X+Y+...). And then I cache the result in a HashMap.

Strangely, changing some loop indices seems to make the problem go away. In particular, if I replace

for (int z = 1; z < x+1; z++) {
    double logSummand = Math.log(z + x + y);
    toReturn.addLogSummand(logSummand);
}

with

for (int z = 0; z < x; z++) {
    double logSummand = Math.log(1 + z + x + y);
    toReturn.addLogSummand(logSummand);
}

then I don't get the error message and the program runs fine.

My minimal example is below:

import java.util.Arrays;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
public class TestLogSum {
    public static void main(String[] args) {

        for (int i = 0; i < 6; i++) {
            for (int n = 2; n < 30; n++) {
                for (int j = 1; j <= n; j++) {
                    for (int k = 1; k <= j; k++) {
                        System.out.println(computeSum(k, j));                       
                    }
                }
            }
        }
    }

    private static Map<List<Integer>, Double> cache = new HashMap<List<Integer>, Double>();
    public static double computeSum(int x, int y) {     
        List<Integer> key = Arrays.asList(new Integer[] {x, y});

        if (!cache.containsKey(key)) {

            // explicitly creating/updating a double[] array, instead of using the LogSumArray wrapper object, will prevent the error
            LogSumArray toReturn = new LogSumArray(x);

            // changing loop indices will prevent the error
            // in particular, for(z=0; z<x-1; z++), and then using z+1 in place of z, will not produce error
//          for (int z = 0; z < x; z++) {
//              double logSummand = Math.log(1 + z + x + y);
            for (int z = 1; z < x+1; z++) {
                double logSummand = Math.log(z + x + y);
                toReturn.addLogSummand(logSummand);
            }

            // returning the value here without cacheing it will prevent the segfault
            cache.put(key, toReturn.retrieveLogSum());
        }
        return cache.get(key);
    }

    /*
     * Given a bunch of logarithms log(X),log(Y),log(Z),...
     * This class is used to compute the log of the sum, log(X+Y+Z+...)
     */
    private static class LogSumArray {      
        private double[] logSummandArray;
        private int currSize;

        private double maxLogSummand;

        public LogSumArray(int maxEntries) {
            this.logSummandArray = new double[maxEntries];

            this.currSize = 0;
            this.maxLogSummand = Double.NEGATIVE_INFINITY;
        }

        public void addLogSummand(double logSummand) {
            logSummandArray[currSize] = logSummand;
            currSize++;
            // removing this line will prevent the error
            maxLogSummand = Math.max(maxLogSummand, logSummand);
        }

        public double retrieveLogSum() {
            if (maxLogSummand == Double.NEGATIVE_INFINITY) return Double.NEGATIVE_INFINITY;

            assert currSize <= logSummandArray.length;

            double factorSum = 0;
            for (int i = 0; i < currSize; i++) {
                factorSum += Math.exp(logSummandArray[i] - maxLogSummand);
            }

            return Math.log(factorSum) + maxLogSummand;
        }
    }
}
Neuroticism answered 7/6, 2014 at 20:9 Comment(8)
That is most likely not a bug in your program (simple java programs should never cause a segmentation fault). It might be a bug in your hardware or your jvm implementation. Try a complete memory check and try a different machine.Goodrow
I have only ever encountered this exact error when writing native code (C, C++, etc) through JNI. Are you using native code (not shown in the question) or is it really all Java? As pointed out already, pure Java should never cause a segfault.Marandamarasca
After running the code, I also get a segmentation fault with "java version "1.7.0_55" OpenJDK Runtime Environment (IcedTea 2.4.7) (7u55-2.4.7-2) OpenJDK 64-Bit Server VM (build 24.51-b03, mixed mode)".Goodrow
Radiodef, I'm not using any native code, it's all Java. Fabian, thanks for the confirmation that this is happening on your machine/setup as well.Neuroticism
This triggers an jvm error on java 1.7.0_51 but not on 1.8.0_05 on windows 7 x64. Have you tried using the flag ` -XX:-PartialPeelLoop` as there are similar errors reported and that flag is supposed to "skip" the problematic compiler code. Search for PhaseIdealLoop::idom_no_updateNaji
I encountered pretty much the same error when playing with a recursive Java program once.Alvey
@Augusto, I've tried -XX:-PartialPeelLoop for Java SE 7 on OSX 10.9 and it still breaks. I've also tried flag -XX:-UseLoopPredicate, which doesn't fix this minimal test case, but did seem to prevent the error in another larger project. (sorry for deleting and reposting this comment, I wanted to edit a couple things in it)Neuroticism
I think this should be reported to Oracle. This code does nothing super special, and still, it breaks. Also on my machine.Prejudice
N
16

So after reading the comments, it seems like this is a bug in the JVM that needs to be reported to Oracle. So, I have gone ahead and filed a bug report to Oracle. I'll post updates when I hear back from them.

Thanks to all those who tried the code and found it breaks on your machines as well.

If there is anyone with the ability/inclination to figure out what code in the compiler is causing this error, it would be awesome to hear about it :)

UPDATE: Someone from Oracle responded yesterday, he said he prepared a fix for the bug and also asked to include my code as a regression test :) He didn't explain what the problem was, beyond saying it was in the HotSpot JIT, but he did send me a link with the changes he made, in case anyone is interested: http://cr.openjdk.java.net/~kvn/8046516/webrev/

Neuroticism answered 8/6, 2014 at 20:5 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.