При попытке собрать Cyrus-IMAP 2.5.5 с исполнением юнит-тестов возникает ошибка: Test: badservice ...lt-unit: threads.c:342: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed. Ошибка немного гуглится для для нескольких разных случаев, упоминается krb5 1.13. Упоминание решения не попалось. Откат до libkrb5-1.12-alt2 проблему устраняет.
С 1.13.2-alt1 без изменений.
с libkrb5-1.14.5-alt1.M80P.1 без изменений.
Cyrus-IMAP 3.0.8 и libkrb5-1.16.1-alt2.S1 без изменений (только строка): Test: badservice ...lt-unit: threads.c:353: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed.
У меня не воспроизводится. Вот что я пробовал: Взял из gears cyrus-imapd 3.0.8-alt2 (commit cb42319096123084e1a666d8b28566b1958597ec), поправил в спеке 9 строку чтобы было %def_with unit_tests и запустил gear-hsh --commit относительно свежего Сизифа x86_64. Тест badservice прошёл, зато упал другой тест: Suite: command Test: run ...FAILED 1. cunit/unit.c:115 - CU_FAIL_FATAL("Code under test exited") И это был единственный упавший тест: Run Summary: Type Total Ran Passed Failed Inactive suites 39 39 n/a 0 0 tests 432 432 431 1 0 asserts 829842 829842 829841 1 n/a Elapsed time = 0.080 seconds FAILED 1. ./cunit/command.testc:21 - CU_ASSERT_EQUAL_FATAL(r=-1904809469,0=0) Test: popen_r ...make[3]: *** [Makefile:6607: check-local] Error 141 Что посоветуете?
(In reply to comment #4) > У меня не воспроизводится. Действительно. Вычистил контейнер от всего старого, и собралось. Видимо, в какой-то момент проблема ушла, а я не заметил из-за того, что в ovz-контейнере собираю. Может быть позже посмотрю, что мешало, хотя интерес академический скорее. Копию крнтейнера оставил. > FAILED > 1. ./cunit/command.testc:21 - CU_ASSERT_EQUAL_FATAL(r=-1904809469,0=0) > Test: popen_r ...make[3]: *** [Makefile:6607: check-local] Error 141 Это что-то другое уже, буду смотреть. > Что посоветуете? Пока только могу спасибо сказать за подсказку, этот баг закрываю.
(In reply to comment #5) > > У меня не воспроизводится. > > Действительно. Вычистил контейнер от всего старого, и собралось. В смысле проблема с krb5 на тесте пропала, а не совсем собралось.
(In reply to comment #4) > У меня не воспроизводится. Вот что я пробовал: У меня, оказывается, libkrb5-devel в зависимостях потерялся, потому и собралось. И у меня после чистки контейнера, и, видимо, в хэшере по-этому же.
(In reply to comment #7) > (In reply to comment #4) > > > У меня не воспроизводится. Вот что я пробовал: > > У меня, оказывается, libkrb5-devel в зависимостях потерялся, потому и > собралось. И у меня после чистки контейнера, и, видимо, в хэшере по-этому же. Да, с последним openssl libkrb5-devel перестала приезжать, и её надо добавлять явно. Не знаю, какая часть функционала Cyrus-IMAP пропадает, если libkrb5-devel нет в сборочном окружении, но что-то явно пропадает... Если в спек добавить BuildRequires: libkrb5-devel, то проблема в хешере вполне воспроизводится. Доставив gdb и libkrb5-debuginfo, можно получить backtrace: $ cd /usr/src/RPM/BUILD/cyrus-imapd-3.0.8/cunit $ gdb /usr/src/RPM/BUILD/cyrus-imapd-3.0.8/cunit/.libs/lt-unit [...] (gdb) run backend [...] lt-unit: threads.c:353: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed. lt-unit: threads.c:353: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed. Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 } (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff6542371 in __GI_abort () at abort.c:79 #2 0x00007ffff6539b1a in __assert_fail_base (fmt=0x7ffff668ce88 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7ffff350fe8f "destructors_set[keynum] == 0", file=file@entry=0x7ffff350fe41 "threads.c", line=line@entry=353, function=function@entry=0x7ffff350ffb0 <__PRETTY_FUNCTION__.5908> "krb5int_key_register") at assert.c:92 #3 0x00007ffff6539b92 in __GI___assert_fail (assertion=assertion@entry=0x7ffff350fe8f "destructors_set[keynum] == 0", file=file@entry=0x7ffff350fe41 "threads.c", line=line@entry=353, function=function@entry=0x7ffff350ffb0 <__PRETTY_FUNCTION__.5908> "krb5int_key_register") at assert.c:101 #4 0x00007ffff350b38c in krb5int_key_register (keynum=keynum@entry=K5_KEY_GSS_SPNEGO_STATUS, destructor=destructor@entry=0x0) at threads.c:353 #5 0x00007fffef5647b0 in gss_spnegoint_lib_init () at spnego_mech.c:316 #6 0x00007fffef53ef94 in gssint_mechglue_init () at g_initialize.c:121 #7 gssint_mechglue_init__aux () at g_initialize.c:102 #8 0x00007ffff448be87 in __pthread_once_slow (once_control=0x7fffef772aa0 <gssint_mechglue_init.once>, init_routine=0x7fffef53ef70 <gssint_mechglue_init__aux>) at pthread_once.c:116 #9 0x00007ffff448bf45 in __GI___pthread_once (once_control=once_control@entry=0x7fffef772aa0 <gssint_mechglue_init.once>, init_routine=<optimized out>) at pthread_once.c:143 #10 0x00007ffff350b009 in k5_once (once=once@entry=0x7fffef772aa0 <gssint_mechglue_init.once>, fn=<optimized out>) at threads.c:562 #11 0x00007fffef543067 in gssint_mechglue_initialize_library () at g_initialize.c:156 #12 0x00007fffef5430dd in gss_indicate_mechs (minorStatus=minorStatus@entry=0x7fffffff8f2c, mechSet_out=mechSet_out@entry=0x7fffffff8e98) at g_initialize.c:277 #13 0x00007fffef545078 in gss_indicate_mechs_by_attrs (minor=0x7fffffff8f2c, desired_mech_attrs=0x7fffffff8f30, except_mech_attrs=0x7fffffff8f40, critical_mech_attrs=0x0, mechs=0x7fffef97c1c8) at g_mechattr.c:113 #14 0x00007fffef7779c4 in ?? () from /usr/lib64/sasl2-3/libgs2.so #15 0x00007fffef778c6f in gs2_client_plug_init () from /usr/lib64/sasl2-3/libgs2.so #16 0x00007ffff7160697 in sasl_client_add_plugin () from /lib64/libsasl2.so.3 #17 0x00007ffff716bcf4 in _sasl_load_plugins () from /lib64/libsasl2.so.3 #18 0x00007ffff7160ee9 in sasl_client_init () from /lib64/libsasl2.so.3 #19 0x000000000042f0cc in init_sasl (isclient=1) at ./cunit/backend.testc:1197 #20 set_up () at ./cunit/backend.testc:1302 #21 0x000000000040bfb7 in __cunit_wrap_fixture (name=name@entry=0x4df1c0 "/usr/src/RPM/BUILD/cyrus-imapd-3.0.8/cunit/backend.testc:set_up", fn=fn@entry=0x42ec20 <set_up>) at cunit/unit.c:167 #22 0x000000000042e430 in __cunit_test_badservice () at cunit/backend.testc-cunit.c:16 #23 0x00007ffff6acde91 in ?? () from /usr/lib64/libcunit.so.1 #24 0x00007ffff6ace19f in ?? () from /usr/lib64/libcunit.so.1 #25 0x00007ffff6ace586 in CU_run_suite () from /usr/lib64/libcunit.so.1 #26 0x000000000040b230 in run_tests () at cunit/unit.c:360 #27 main (argc=<optimized out>, argv=<optimized out>) at cunit/unit.c:456 (gdb)
Что характерно, тесты из backend успешно проходят, если их запускать по-одному -- например так: cd /usr/src/RPM/BUILD/cyrus-imapd-3.0.8/cunit for test in `./unit -l | grep backend` ; do ./unit -v "$test"; done Видимо, на данный момент libgssapi_krb5.so.2 не рассчитана на то, что
упс, случайный click (In reply to comment #9) > Видимо, на данный момент libgssapi_krb5.so.2 не рассчитана на то, что ... её будут выгружать, загружать, и снова выгружать, и так далее.
(In reply to comment #8) > если libkrb5-devel нет в сборочном окружении, но что-то явно пропадает... Пропадает поддержка gssapi. Тут проблема ещё в том, что я у себя этот механизм не использую (и через sasl тоже) и не могу быстро оценить реальную работоспособность. (In reply to comment #9) > Что характерно, тесты из backend успешно проходят, если их запускать > по-одному. Видимо, на данный момент libgssapi_krb5.so.2 не рассчитана > на то, что её будут выгружать, загружать, и снова выгружать, и так далее. Интересный вариант. Но когда-то (с 1.12) ведь работало. Что ещё непонятно, это почему больше ни у кого не вылезло при сборке Cyrus-IMAP (хотя вот в Федоре какой-то свой набор тестов используют). Надо у остальных посмотреть.
https://github.com/cyrusimap/cyrus-imapd/issues/2526
libkrb5-1.17.1, воспроизводится.
