#31381 – 1.17.1: threads.c:353: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed

Bug 31381 - 1.17.1: threads.c:353: krb5int_key_register: Assertion `destructors_set[keynum] == 0' failed

Summary: 1.17.1: threads.c:353: krb5int_key_register: Assertion `destructors_set[keynu...

Status:	REOPENED

Alias:	None

Product:	Sisyphus
Classification:	Development
Component:	libkrb5 (show other bugs)
Version:	unstable
Hardware:	all Linux

Importance:	P3 normal
Assignee:	Ivan A. Melnikov
QA Contact:	qa-sisyphus

URL:
Keywords:

Depends on:
Blocks:

Reported:	2015-10-19 18:10 MSK by Sergey Y. Afonin
Modified:	2020-06-28 23:39 MSK (History)
CC List:	2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description

Sergey Y. Afonin 2015-10-19 18:10:48 MSK

При попытке собрать 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 проблему устраняет.

Comment 1

Sergey Y. Afonin 2015-10-21 09:55:32 MSK

С 1.13.2-alt1 без изменений.

Comment 2

Sergey Y. Afonin 2017-08-23 11:36:32 MSK

с libkrb5-1.14.5-alt1.M80P.1 без изменений.

Comment 3

Sergey Y. Afonin 2018-09-13 09:52:32 MSK

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.

Comment 4

Ivan A. Melnikov 2018-09-13 10:41:59 MSK

У меня не воспроизводится. Вот что я пробовал:

Взял из 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

Что посоветуете?

Comment 5

Sergey Y. Afonin 2018-09-13 14:32:11 MSK

(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

Это что-то другое уже, буду смотреть.

> Что посоветуете?

Пока только могу спасибо сказать за подсказку, этот баг закрываю.

Comment 6

Sergey Y. Afonin 2018-09-13 14:37:56 MSK

(In reply to comment #5)

> > У меня не воспроизводится.
> 
> Действительно. Вычистил контейнер от всего старого, и собралось.

В смысле проблема с krb5 на тесте пропала, а не совсем собралось.

Comment 7

Sergey Y. Afonin 2018-09-14 09:32:55 MSK

(In reply to comment #4)

> У меня не воспроизводится. Вот что я пробовал:

У меня, оказывается, libkrb5-devel в зависимостях потерялся, потому и собралось. И у меня после чистки контейнера, и, видимо, в хэшере по-этому же.

Comment 8

Ivan A. Melnikov 2018-09-14 12:10:45 MSK

(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)

Comment 9

Ivan A. Melnikov 2018-09-14 12:43:06 MSK

Что характерно, тесты из 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 не рассчитана на то, что

Comment 10

Ivan A. Melnikov 2018-09-14 12:44:06 MSK

упс, случайный click

(In reply to comment #9)
> Видимо, на данный момент libgssapi_krb5.so.2 не рассчитана на то, что
... её будут выгружать, загружать, и снова выгружать, и так далее.

Comment 11

Sergey Y. Afonin 2018-09-14 13:57:04 MSK

(In reply to comment #8)

> если libkrb5-devel нет в сборочном окружении, но что-то явно пропадает...

Пропадает поддержка gssapi. Тут проблема ещё в том, что я у себя этот механизм не использую (и через sasl тоже) и не могу быстро оценить реальную работоспособность.

(In reply to comment #9)

> Что характерно, тесты из backend успешно проходят, если их запускать
> по-одному. Видимо, на данный момент libgssapi_krb5.so.2 не рассчитана
> на то, что её будут выгружать, загружать, и снова выгружать, и так далее.

Интересный вариант. Но когда-то (с 1.12) ведь работало. Что ещё непонятно, это почему больше ни у кого не вылезло при сборке Cyrus-IMAP (хотя вот в Федоре какой-то свой набор тестов используют). Надо у остальных посмотреть.

Comment 12

Sergey Y. Afonin 2018-09-17 11:56:35 MSK

https://github.com/cyrusimap/cyrus-imapd/issues/2526

Comment 13

Sergey Y. Afonin 2020-06-28 23:39:15 MSK

libkrb5-1.17.1, воспроизводится.