Gracias por informar de esto, tendré que mirar más de cerca.

Lamento mucho que me haya tomado tanto tiempo volver a este @ mvo5 , agradezco su paciencia.

Para aclarar un poco las cosas, el db.c actual relevante: db_col_db_add () se ve así:

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

... Creo que la versión anterior en el informe de problema original era una copia parcheada localmente para solucionar el problema. Dicho esto, cambiar el error devuelto aquí suena razonable; hemos estado usando EDOM en al menos algunos de los otros códigos arch / endian, ¿te suena razonable?

¿Qué opinas @mheon?

Parece que probablemente también deberíamos actualizar db.c: db_col_merge () mientras lo hacemos.

Desde el punto de vista de la API, definitivamente creo que tiene sentido hacer el cambio: la sobrecarga de códigos de error siempre es problemática para la depuración.

En el lado de libseccomp-golang, esto no debería requerir ningún cambio de código, siempre que se mantenga la convención ERRNO negativa; tal vez algunas líneas de comentarios sobre AddArch para explicar qué significa el nuevo error, para que la documentación de la API esté completa.

Travis todavía está ejecutando un kernel demasiado antiguo, por lo que la prueba # 47 falló nuevamente. Como @pcmoore mencionó hace un tiempo, intentaré agregar algo de inteligencia a la prueba para evitar esto.

De lo contrario, todo lo demás de este cambio se ve bien en mi libro.

@drakenclimber Creo que te refieres a la prueba 46, no a la 47, ¿verdad?

Hace unos meses agregué la verificación de nivel de API para las pruebas en vivo, pero no creo que lo necesitemos para las pruebas bpf-sim, ¿verdad? ¿Las pruebas de bpf-sim se estaban ejecutando limpias ...?

Travis definitivamente vomitó en la prueba # 47 (KILL_PROCESS) para la ejecución anterior. También vi el mismo fallo en la CABEZA del maestro esta mañana cuando la empujé a una rama separada como prueba de cordura.

Prueba 47-live-kill_process %% 001-00001 resultado: FALLO 47-live-kill_process 3 KILL_PROCESS rc = 12

Hablamos de esto hace bastante tiempo, así que mi memoria puede estar confusa, pero pensé que Travis tenía problemas con la prueba KILL_PROCESS porque el kernel de Travis es anterior a 4.14 cuando se introdujo esa característica.

¿O estoy loco ... y recuerdo mal por completo?

Hmm, ¿estamos viendo el mismo registro? Estoy mirando la compilación y el registro a continuación:

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

... que muestran los siguientes resultados (solo copiaron las pruebas "c" aquí, los resultados de "python" fueron los mismos):

 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)

... y sí, los núcleos más antiguos tienen un problema con algunas de las pruebas en vivo, pero eso debería haberse solucionado en 9d4f7f69714d5af80309aa1b8a6d2c8300bb6730.

FWIW, la última compilación de Travis en la rama maestra se ejecutó sin problemas:

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

Acabo de activar una nueva compilación usando la rama maestra solo para verificar que todo esté "OK" con Travis:

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

Admito que ahora estoy _realmente_ confundido. Su enlace definitivamente muestra que la prueba # 46 es el problema. Pero cuando hago clic en el enlace "Registro sin procesar" en la esquina superior derecha, me dice que # 47 falló. Para el enlace que enumeró anteriormente, aquí es donde el registro sin procesar me redirigió:

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

Entonces, mirando más de cerca, creo que ambos tenemos razón.

46 devuelve ERROR como señaló. Y # 47 está devolviendo FAILURE (que es lo que había buscado originalmente).

Y esto también es visible en los resúmenes:

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

Puedo reproducir los problemas de TravisCI en uno de mis sistemas si arranco en un kernel 3.x. La prueba 46 termina teniendo problemas en sys_chk_seccomp_action () . Esto finalmente hace que seccomp_init () devuelva un contexto NULL a la prueba.

Me imagino que los problemas de la Prueba 47 son similares, pero no investigué su ruta de falla. (Aunque el cambio que @pcmoore agregó para verificar la API debería haber evitado esto. Hmmm ...)

Tendría curiosidad por saber qué ha cambiado en Travis para causar esto. ¿Recurrieron a un núcleo realmente antiguo? ¿Algo de nuestro lado?

Parece que necesitaremos agregar algo de inteligencia a las pruebas bpf-sim para manejar esto. ¿Queremos imitar la columna API agregada al archivo * .tests o hacer algo completamente diferente?

Sí, estoy realmente confundido en cuanto a por qué estaba funcionando como ahora no lo está. Ubuntu 14.xx es muy antiguo estos días, voy a ver si hay una versión más reciente disponible en Travis.

Parece que Ubuntu 16.04 (Xenial) está disponible, intentemos eso ...

Commit 06f63ba691cb9df119c6759e8f0a150a2a9cbe69 nos lleva a Ubuntu 16.04. Estoy haciendo esto en la rama maestra, no como PR, porque quiero forzar este cambio; si la construcción se rompe, lo arreglaremos.

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

Esa compilación parecía haber solucionado el problema con las pruebas, pero clang acaba de encontrar una pérdida de memoria en una ruta de código de manejo de errores. Lo arreglaré en un minuto.

¡Impresionante! Gracias por la ayuda, @pcmoore

Bien, con la confirmación f8854f990004e71ccb9955c33d88d82cdb97ea42 deberíamos tener una rama maestra de construcción limpia. Funcionó bien en mi rama personal, esperando la compilación principal ahora.

@drakenclimber Veo que tienes un parche listo para esto en el registro de problemas anterior, pero todavía no veo un PR. ¿Todavía estás persiguiendo algunos problemas con el parche o está listo para un PR?

Esto debería resolverse con la confirmación 4a35b6ea6f7c836734536420c50a2745a9e24c69, cerrando esto ahora. Si alguien encuentra un problema con esto, vuelva a abrir este problema o cree uno nuevo.