SIGSEGV in rehashFunctors

[Wouter1]

When I run the following program, I get a SIGSEGV in libswipl.so.7.4 rehashFunctors in roughly half of the times I run it.

to reproduce, save this program in a file "test.java" and follow the instructions in the comments.

On faster machines, you may have to increase the constant "88" to a higher value to reproduce the issue.

The machine I reproduced this on is a somewhat older machine: Ubuntu 16.04 LTS (freshly installed from scratch yesterday) 7.7GB main memory Intel Core i5-4590 CPU @3.3GHz x 4 Intel Haswell Desktop

openjdk version "1.8.0_131" OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-2ubuntu1.16.04.3-b11) OpenJDK 64-Bit Server VM (build 25.131-b11, mixed mode)

swi prolog 7.4.2 and jpl was built from sources

/**
 * compile with: javac -classpath .:/usr/local/lib/swipl-7.4.2/lib/jpl.jar test.java
 * run: java -classpath .:/usr/local/lib/swipl-7.4.2/lib/jpl.jar -Djava.library.path=/usr/local/lib/swipl-7.4.2/lib/x86_64-linux/ test
*/

import java.util.ArrayList;
import java.util.List;

import org.jpl7.Query;

public class test {

    public static void main(String[] args) throws InterruptedException {
        System.out.println("Multi-thread test insert/delete");
        List<Thread> threads = new ArrayList<>();
        for (int n = 0; n < 88; n++) {
            threads.add(runThreadInsertDelete(n));
        }
        while (!threads.isEmpty()) {
            Thread thread = threads.get(0);
            // System.out.println("Waiting for " + thread);
            thread.join();
            threads.remove(thread);
        }
    }

    private static Thread runThreadInsertDelete(final int n) {
        Thread thread = new Thread(new Runnable() {
            @Override
            public void run() {
                try {
                    testInsertDelete(n);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        });
        thread.start();
        return thread;
    }

    private static void testInsertDelete(int n) throws InterruptedException {
        long endTime = System.currentTimeMillis() + 5000;

        while (System.currentTimeMillis() < endTime) {
            double random = Math.random();
            new Query("assert(r(" + random + "))").allSolutions();
            if (new Query("aggregate_all(count,r(_),Amount)").allSolutions().length < 1) {
                System.err.println("WARNING. Expected r to hold after insert");
            }
            new Query("retract(r(" + random + "))").allSolutions();
        }
    }
}

[Wouter1]

BTW that query to check the number solutions is not designed properly, but I didn't change it as it may be an essential part to reproduce the issue.

[JanWielemaker]

This does reproduce. Investigating.

[Wouter1]

@JanWielemaker Thanks for the quick response!

[JanWielemaker]

Should be fixed with SWI-Prolog/swipl-devel@13dc4450d6f36099ce4440104bc69385f3c25283. It will probably cherry-pick to 7.4.2. I'm afraid 7.4.2 was supposed to be a maintained stable release, but this failed. Please use the swipl-devel.git version. Please verify and close if you are satisfied.

[Wouter1]

@JanWielemaker wow that was really quick! Thanks. I will discuss if we want to switch to the develop branch to pick up this.

Using a development branch might introduce new issues? Or is the current development branch only for bug fixes?

[JanWielemaker]

Surely the development branch has issues from time to time. Most of the time it is more reliable though. The last word hasn't been said about which version to pick. It depends what you are doing, notably on what parts of the system you rely most. I think for many projects the right advice is to develop while following the development branch. Once you approach production, you stop following the latest git and merely scan the patches for relevant fixes and cherry pick those.

We plan to coordinate that better. That was already planned for 7.4.x, but I'm afraid we failed. If you want to help or be involved in the discussion when we plan for 7.6 (a month or so), please drop a mail.

[Wouter1]

@JanWielemaker we are definitely aiming for a stable release as this will be our next SWI version for some time to come (typically a year or so).

If you want to help or be involved in the discussion when we plan for 7.6 (a month or so), please drop a mail.

I suppose you suggest that we would also test SWI when it's almost ready. We only update SWI in GOAL once in a year or so because of the amount of work involved in it. What is the update frequency of SWI? Maybe we can get that in sync. Are you saying the 7.6 release will be in about a month?

BTW1 we have a nice java-maven system that automatically installs SWI in a temp directory, whether it's linux, osx or windows. This allows us to provide end users with a single java file that will run swi code internally, regardless of the operating system. Basically you just put this in your POM

  <dependency>
      <groupId>${project.groupId}</groupId>
      <artifactId>swiPrologEnabler</artifactId>
      <version>${project.version}</version>
  </dependency>

and you can run SWI prolog from your java code. I can imagine other SWI+JPL users would love to have this . Unfortunately the docs are hard to find because it's part of a bigger project, https://bitbucket.org/goalhub/krtools/overview but I might pull some bells if you think it would be worth to do so.

BTW2 I'm glad that there is a 'traditional' flag in SWI, that saves us from a lot of upgrading work in our code.

[Wouter1]

BTW here https://github.com/goalhub/krTools/tree/master/krLanguages/swiprologlibs is an OLD version of the enabler, but it has at least a little bit of documentation.

[JanWielemaker]

I suppose you suggest that we would also test SWI when it's almost ready. We only update SWI in GOAL once in a year or so because of the amount of work involved in it. What is the update frequency of SWI? Maybe we can get that in sync. Are you saying the 7.6 release will be in about a month?

The advantage of using the devel version for your own development is that you can quickly spot incompatible and buggy developments. I wonder why updating is so hard. Isn't it just pulling a new version and rebuilding? SWI doesn't have a clear policy about when stable versions are released. They are merely snapshots, typically created when the stable version is considered to lack behind too far and sometimes before starting big changes that may impact stability.

I expect 7.6 in a month, maybe two.

As for the Java stuff, that is not my cup of tea. I'm happy to include stuff in the JPL distro and/or put it somewhere on the website, but I have no opinion about it.