Почему отваливаются колбэки jna?

Question

[nuclear_kote]

раз в секунду сишный код дергает ~150 раз java колбэк. Через какое то время на стороне java реакция прекращается, сишный же код продолжает работу и никак не блокируется. Что это может быть?

Comments

[pi314]

Может быть OutOfMemory в JVM (почему - вопрос к автору кода), когда JVM уже не жива, но еще не мертва. Что значит сишный код "не блокируется"? В дебагере смотрели? Возврат из коллбека происходит, с ожидаемым результатом за ожидаемое время?

[nuclear_kote]

pi314, >Может быть OutOfMemory в JVM (почему - вопрос к автору кода)
жаба код продолжает выполняться тоже. Только значения через колбэки перестают меняться.
>Что значит сишный код "не блокируется"?
в сишном коде переменные сразу за колбэком (i++) отрабатывает и выводится раз в секунду изменения

[MaxLich]

nuclear_kote, а что по логам в джаве коде? может какие-то тихие исключения срабатывают?

[nuclear_kote]

MaxLich, код java абсолютно тупой для теста нечему там падать по идее

public class Test {
    public static void main(String[] args) throws InterruptedException {
        TestLib lib = Native.loadLibrary("hello", TestLib.class);

        for (int i = 0; i < 10; i++) {
            lib.registerCallback(new TestCallback());
        }
        new Thread(() -> {
            while (true) {
                try {
                    System.out.println("-------------------"  + TestCallback.i.getAndSet(0) + "  === " );
                    lib.printInfo();
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
        for (int i = 1; i <= 32; i++) {
            new Thread(() -> lib.start()).start();
        }
    }

    public static class TestCallback implements Callback {
        static AtomicLong i = new AtomicLong(0);
        public void callback(ArrayStruct hdrs) {
            i.addAndGet(hdrs.size);
        }

    }

    public static class ArrayStruct extends Structure {

        public int size;
        public TestStruct.ByReference list;

        public ArrayStruct() {
        }

        public ArrayStruct(Pointer peer) {
            super(peer);
            read();
        }
        @Override
        protected List<String> getFieldOrder() {
            return Arrays.asList("size", "list");
        }
    }
    public static class TestStruct extends Structure {

        public String strField;
        public int intField;

      public String getStrField() {
            return strField;
        }

        public void setStrField(String strField) {
            this.strField = strField;
        }


        public TestStruct() {
        }

        public TestStruct(Pointer peer) {
            super(peer);
            read();
        }
        public int getIntField() {
            return intField;
        }

        public void setIntField(int intField) {
            this.intField = intField;
        }

        @Override
        protected List<String> getFieldOrder() {
            return Arrays.asList("strField", "intField");
        }

        public static class ByReference extends TestStruct implements Structure.ByReference {}

    }

}

[MaxLich]

nuclear_kote, код не полный, но возможно где-то есть NullPointerException или попытка изменить неизменямый лист (который получается методом Arrays.asList()). В этом коде могут быть только такие ошибки, больше ничего такого не видно (если смотреть по-быстрому). Я бы добавил выводы в лог в функцию, которая вызывается (я так полагаю это lib.start())

ЗЫ Хотя я не специалист работы с сишным кодом из джавы. На своём последнем проекте использовал COM4J для работы с COM-объектами.

[pi314]

nuclear_kote, А что с методом lib.start() - он блокирующий или нет? И зачем он дергается 31 раз из разных потоков... В чем тут сутъ?

[nuclear_kote]

pi314, там бесконечный цикл который с сокета слушает. он не блокируется. в нем изменения переменных идут

[pi314]

nuclear_kote, ну, значит, таки блокирующий )) если в нем бесконечный цикл )) 31 user thread уходят в него и никогда не возвращаются. Вы уверены, что хорошо понимаете, кто кому Рабинович в многопоточности? В приведенном коде ничего не может отваливаться. Эти самые 31 поток уходят, каждый в метод start() (нативный код), там колбасятся, что-то делают с сокетами, а потом, очевидно, приходят в явовский метод callback(), очевидно, каждый в каждый из 10 созданных экземпляров, и все, что они там делают - увеличивают один единственный счетчик, статический, после чего возвращаются в нативный код, где "изменяют переменные" и продолжают колбаситься в бесконечном цикле. Если это так, то тут нечему отваливаться. Единственное, что может произойти - они могут застрять в нативном коде и никогда не вернуться. Я смоделировал это вот так, чтоб не заморачиваться с JNA и стабами. Помимо, мягко говоря, странного дизайна (возможно, он чем-то оправдан, не берусь судить), никаких проблем не возникает ))

package ex.ample;

import java.util.ArrayList;
import java.util.concurrent.ThreadLocalRandom;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicLong;


public class Main {
    public static void main(String[] args) {
        //TestLib lib = Native.loadLibrary("hello", TestLib.class);
        final TestLib lib = new TestLib();

        for (int i = 0; i < 5; i++) {
            lib.registerCallback( new TestCallback() );
        }
        new Thread(() -> {
            while (true) {
                try {
                    String msg = "-------------------"  + TestCallback.counter.get() + "  ===\n";
                    msg += lib.printInfo();
                    System.out.println(msg + "\n-RESET COUNTER ----"  + TestCallback.counter.getAndSet(0) + "->0 ==" );
                    TimeUnit.SECONDS.sleep(1);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }).start();
        for (int i = 1; i < 5+1; i++) {
            new Thread(() -> lib.start()).start();
        }
        System.out.println("---\nExiting main()...\n---");
    }

    interface ICallback {
        void callback(int inc);
        String printStatistic();
    }

    public static class TestCallback implements ICallback{
        static AtomicLong counter = new AtomicLong(0);
        private final AtomicLong totalIncCounter = new AtomicLong(0);
        @Override
        public void callback(int inc) {
            counter.addAndGet(inc);
            totalIncCounter.addAndGet(1L);
        }

        @Override
        public String printStatistic() {
            return "cb#" + this.hashCode() + " \tcalled " + totalIncCounter.get() + " times,\tcurrently at "+ counter.get();
        }

    }

    public static class TestLib {

        private final ArrayList<ICallback> registeredCallbacks = new ArrayList<>();

        public void registerCallback(Main.ICallback cb){
            registeredCallbacks.add(cb);
        }

        public String printInfo(){
            String res = "";
            for(Main.ICallback cb : registeredCallbacks){
                res += cb.printStatistic()+"\n";
            }
            return res;
        }


        public void start(){
            while(true){
                for(Main.ICallback cb : registeredCallbacks){
                    try {
                        TimeUnit.MILLISECONDS.sleep(ThreadLocalRandom.current().nextInt(300, 700+1) );
                        int incrementThisTime = ThreadLocalRandom.current().nextInt(1, 5+1);
                        String msg = "Thread " + Thread.currentThread().getId() + "\nbefore\t" + cb.printStatistic() + "\tincrement " + incrementThisTime;
                        cb.callback(incrementThisTime);
                        System.out.println(msg + "\nafter\t" + cb.printStatistic());
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                        break;
                    }
                }
            }
        }
    }
}

Мораль: если что-то отваливается, причину нужно искать в сишном коде. Возможно, в нем создаются еще какие-то левые потоки, которые, на самом деле, "изменяют переменные"... состояние явовских потоков можно всегда посмотреть в jconsole. Но, в любом случае, нужно разобраться, какой код в каком потоке выполняется - без этого трудно сделать какие-либо предположения.
P.S. да, еще соображение вдогонку: если мое предположение неверно, и в метод callback() на самом деле приходит не созданный в яве поток, а поток, созданный в сишном коде, то там и нужно смотреть, почему он отваливается.

[nuclear_kote]

pi314, > Я смоделировал это вот так, чтоб не заморачиваться с JNA и стабами.
там очень высокая производительность нужна + там низкоуровневые функцию юзаются.
>31 user thread уходят в него и никогда не возвращаются
це было бы понятно и не так странно если бы оно изначально колбеки не дергало бы, а оно отваливается только минут через 5.
>Вы уверены, что хорошо понимаете, кто кому Рабинович в многопоточности?
понимал бы если бы была бы чисто жаба. а с си я вообще мало чего понимаю

[pi314]

nuclear_kote, Ну попробуйте тогда сначала изолировать проблему. Первым делом разберитесь, какой поток приходит в коллбек - явовский или (левый) сишный. Чудес не бывает, а код и потоки - они и в африке, и в яве, и в си одни и те же. Разница только в том, что JVM ничего не знает о происходящем в нативном коде. Замените сишную библиотеку явовским моком, типа, как я сделал, и посмотрите, отваливается или нет. По крайней мере станет понятно, где проблема.
Потом, если "только минут через 5", посмотрите, не связано ли это с GC. Возможно, где-то медленно утекает память. Пока ее хватает, работает, потом - отваливается. Для проверки дайте JVM поменьше памяти и проверьте, не наступает ли эффект быстрее. Если так, то нужно смотреть структуры данных, которые гоняются между явой и нативным кодом... кто их создает, кто удерживает ссылки. Посмотрите, что происходит с потоками и памятью в jconsole, нет ли явных различий в поведении JVM до отваливания и после. Короче, гадание на кофейной гуще не поможет. Если не локализовать проблему, никто не даст такой волшебный совет, от которого все само собой заработает ))

[pi314]

nuclear_kote, А, так вот же, в доке по JNA черным по-английски написано:

If your callback needs to live beyond the method invocation where it is used, make sure you keep a reference to it or the native code will call back to an empty stub after the callback object is garbage collected

В приведенном коде экземпляры коллбеков создаются (new TestCallback()), но нигде не сохраняются. После выхода из main() GC имеет полное право их убить, когда сочтет нужным, и нативные коллбеки будут уходить в Нирвану... что, похоже, и происходит))