Спасибо, что сообщили об этом, мне нужно будет посмотреть поближе.

Мне очень жаль, что у меня ушло так много времени, чтобы вернуться к этому спасибо за ваше терпение.

Чтобы немного прояснить ситуацию, соответствующий текущий db.c: db_col_db_add () выглядит так:

        if (col->endian != 0 && col->endian != db->arch->endian)
                return -EEXIST;

... Я думаю, что версия, указанная выше в исходном отчете о проблеме, была локально исправленной копией для решения проблемы. Тем не менее, изменение возвращаемой ошибки здесь звучит разумно; мы использовали EDOM, по крайней мере, в каком-то другом коде с прямым и обратным порядком байтов, это звучит разумно для вас?

Как ты думаешь @mheon?

Похоже, нам, вероятно, также следует обновить db.c: db_col_merge (), пока мы на нем.

С точки зрения API, я определенно думаю, что это изменение имеет смысл - перегрузка кодов ошибок всегда проблематична для отладки.

На стороне libseccomp-golang это не должно требовать каких-либо изменений кода, если соблюдается отрицательное соглашение ERRNO; возможно, несколько строк комментариев к AddArch, чтобы объяснить, что означает новая ошибка, так что документация по API будет полной.

Трэвис все еще использует слишком старое ядро, поэтому тест № 47 снова не прошел. Как некоторое время назад упоминал @pcmoore , я постараюсь добавить в тест немного умов, чтобы этого избежать.

В остальном все остальное из этого изменения выглядит хорошо в моей книге

@drakenclimber Я думаю, вы имеете в виду тест 46, а не 47, верно?

Несколько месяцев назад я добавил проверку уровня API для живых тестов, но я не думаю, что нам это нужно для тестов bpf-sim, не так ли? Тесты bpf-sim прошли без ошибок ...?

Трэвиса определенно вырвало во время теста № 47 (KILL_PROCESS) вышеупомянутого прогона. Я также видел тот же сбой в ГОЛОВЕ мастера этим утром, когда я перенес его в отдельную ветку для проверки работоспособности.

Результат теста 47-live-kill_process %% 001-00001: FAILURE 47-live-kill_process 3 KILL_PROCESS rc = 12

Мы говорили об этом довольно давно, поэтому моя память может быть туманной, но я подумал, что у Трэвиса были проблемы с тестом KILL_PROCESS, потому что ядро ​​Трэвиса старше 4.14, когда эта функция была представлена.

Или я сошел с ума ... и совсем не помню?

Хм, мы смотрим на тот же журнал? Я смотрю на сборку и журнал ниже:

• https://travis-ci.org/drakenclimber/libseccomp/builds/488643921
• https://api.travis-ci.org/v3/job/488643923/log.txt

... которые показывают следующие результаты (здесь были скопированы только тесты "c", результаты "python" были такими же):

 batch name: 46-sim-kill_process
 test mode:  c
 test type:  bpf-sim
Test 46-sim-kill_process%%001-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%002-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%003-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%004-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%005-00001 result:   ERROR 46-sim-kill_process rc=12
Test 46-sim-kill_process%%006-00001 result:   ERROR 46-sim-kill_process rc=12
 batch name: 47-live-kill_process
 test mode:  c
 test type:  live
Test 47-live-kill_process%%001-00001 result:   SKIPPED (must specify live tests)

... и да, у старых ядер действительно есть проблемы с некоторыми живыми тестами, но это должно было быть исправлено в 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730.

FWIW, последняя сборка Travis в основной ветке прошла без ошибок:

• https://travis-ci.org/seccomp/libseccomp/builds/431949896

Я просто запустил новую сборку, используя главную ветку, чтобы убедиться, что с Трэвисом все в порядке:

• https://travis-ci.org/seccomp/libseccomp/jobs/488759868

Признаюсь, сейчас я действительно озадачен. Ваша ссылка определенно показывает, что проблема в тесте № 46. Но когда я нажимаю ссылку «Raw Log» в правом верхнем углу, мне сообщается, что # 47 не удалось. Для ссылки, которую вы указали выше, меня перенаправили сюда необработанный журнал:

• https://api.travis-ci.org/v3/job/488643923/log.txt

Итак, если присмотреться, я думаю, что мы оба правы.

46 возвращает ERROR как вы указали. И # 47 возвращает FAILURE (это то, что я искал изначально).

И это тоже видно в аннотациях:

Regression Test Summary
 tests run: 14090
 tests skipped: 114
 tests passed: 14090
 tests failed: 0
 tests errored: 12

Regression Test Summary
 tests run: 16
 tests skipped: 0
 tests passed: 14
 tests failed: 2
 tests errored: 0

Я могу воспроизвести проблемы TravisCI на одной из моих систем, если загрузлюсь в ядро ​​3.x. В тесте 46 возникают проблемы с sys_chk_seccomp_action () . В конечном итоге это приводит к тому, что seccomp_init () возвращает тесту NULL-контекст.

Я мог бы предположить, что проблемы Test 47 схожи, но я не исследовал путь его отказа. (Хотя изменение @pcmoore, добавленное для проверки API, должно было предотвратить это. Хммм ...)

Мне было бы любопытно, что изменилось в Трэвисе, чтобы вызвать это. Они вернулись к действительно старому ядру? Что-то с нашей стороны?

Похоже, нам нужно будет добавить немного умов в тесты bpf-sim, чтобы справиться с этим. Хотим ли мы имитировать столбец API, добавленный в файл * .tests, или сделать что-то совсем другое?

Да, я действительно не понимаю, почему он работал так, как сейчас. Ubuntu 14.xx действительно устарел, я собираюсь посмотреть, есть ли более свежая версия, доступная на Travis.

Похоже, доступна Ubuntu 16.04 (Xenial), давайте попробуем ...

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 поднимает нас до Ubuntu 16.04. Я делаю это в главной ветке, а не как пиарщик, потому что хочу принудительно включить этот переключатель; если сборка сломается, мы это исправим.

• https://travis-ci.org/seccomp/libseccomp/builds/489230929

Эта сборка, похоже, устранила проблему с тестами, но clang только что обнаружил утечку памяти в пути кода обработки ошибок. Я исправлю это через минуту.

Потрясающие! Спасибо за помощь, @pcmoore

Хорошо, с фиксацией f8854f990004e71ccb9955c33d88d82cdb97ea42 у нас должна быть чистая главная ветка здания. Он отлично работал в моей личной ветке, ожидая сейчас основной сборки.

@drakenclimber Я вижу, что у вас есть готовый патч в журнале проблем выше, но я еще не вижу PR - вы все еще преследуете некоторые проблемы с патчем или он готов к PR?

Это должно быть решено с помощью commit 4a35b6ea6f7c836734536420c50a2745a9e24c69, закрывая это сейчас. Если кто-то обнаружит проблему с этим, пожалуйста, откройте эту проблему повторно или создайте новую.