После обновления до * Ср мар 22 2017 Vladimir D. Seleznev <vseleznv@altlinux.org> 3.5.1-alt7.qa1 - NMU: rebuilt against Tcl/Tk 8.6. получил $ python3 Fatal Python error: getentropy() failed Ошибка сегментирования
Проблема в отсутствии на $ uname -a Linux pbf64.office.etersoft.ru 2.6.32-ovz-el-alt147 #1 SMP Fri Oct 28 17:45:13 UTC 2016 x86_64 GNU/Linux системного вызова: getrandom(0x8e05f0, 24, 0) = -1 ENOSYS (Function not implemented) write(2, "Fatal Python error: getentropy()"..., 40Fatal Python error: getentropy() failed ) = 40 Ошибка должна воспроизводится с $ strace -e fault=getrandom python3 У меня подозрение, что новый glibc предоставил обёртку для getrandom приложению, а приложение не может корректно обработать ошибку вызова этой функции.
$ uname -r 4.9.18-std-def-alt1 $ rpm -q glibc glibc-2.25-alt2.x86_64 $ python3 Python 3.5.1 (default, Apr 7 2017, 11:25:29) [GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> ^D $ strace -o /dev/null -e fault=getrandom python3 Fatal Python error: getentropy() failed zsh: segmentation fault strace -o /dev/null -e fault=getrandom python3
(In reply to comment #1) > Проблема в отсутствии на > $ uname -a > Linux pbf64.office.etersoft.ru 2.6.32-ovz-el-alt147 #1 SMP Fri Oct 28 17:45:13 > UTC 2016 x86_64 GNU/Linux > > системного вызова: > getrandom(0x8e05f0, 24, 0) = -1 ENOSYS (Function not implemented) > write(2, "Fatal Python error: getentropy()"..., 40Fatal Python error: > getentropy() failed > ) = 40 > > Ошибка должна воспроизводится с > $ strace -e fault=getrandom python3 > > У меня подозрение, что новый glibc предоставил обёртку для getrandom > приложению, > а приложение не может корректно обработать ошибку вызова этой функции. По-моему, python3 даже в некотором смысле обработал эту ошибку (ведь кто-то написал: Fatal Python error), но он написан так, что считает, что эта функция в нормальной ситуации не возвращает ошибку. Если верно предположение о том, что вызывается обёртка над системным вызовом из glibc, получается, что glibc считает нормальным вернуть ошибку (и пусть приложение разбирается), а приложение считает, что ненормально (и glibc должна была сама разобраться, раз уж предоставило такое API). Какое поведение функции из glibc более правильное? (Интересно: а тесты же python3 проходили в сборочнице. Там какое-то другое ядро?)
Просто в Сизифе старый глючный питон, не рассчитанный на современные ядра и glibc.
(In reply to comment #2) > $ uname -r > 4.9.18-std-def-alt1 > $ rpm -q glibc > glibc-2.25-alt2.x86_64 > $ python3 > Python 3.5.1 (default, Apr 7 2017, 11:25:29) > [GCC 6.3.1 20170118 (ALT 6.3.1-alt2)] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> ^D > $ strace -o /dev/null -e fault=getrandom python3 > Fatal Python error: getentropy() failed > zsh: segmentation fault strace -o /dev/null -e fault=getrandom python3 Я, наоборот, понял, что на более современных ядрах питон не падает, как видно здесь. (Возможно, он и на ядре в сборочнице не падает.) А этот системный вызов он в итоге делает всегда при просто запуске, раз если его явно зафейлить с помощью strace, то он падает. Я подумал, что функция в glibc стала возвращать ошибку на более старых ядрах (дело не в неадаптированности python3 к новым ядрам), либо python3 после пересборки стал вызывать другую функцию из glibc, которая возвращает ошибку на более старых ядрах (недоделка в python3).
(In reply to comment #4) > Просто в Сизифе старый глючный питон, не рассчитанный на современные ядра и > glibc. В Сизифе как раз достаточно свежие питоны (и я не знаю версии питонов, которые будучи собранными в окружении с современными ядрами и glibc, не работали с ними). Проблема проявляется, как я понял, на openvz-ядрах с glibc-2.25. Похоже, что-то поменялось в поведении glibc.
python3-3.5.1-alt8 -> sisyphus: * Tue Apr 11 2017 Gleb F-Malinovskiy <glebfm@altlinux> 3.5.1-alt8 - Fixed interpreter breakage caused by rebuild with glibc >= 2.25 (closes: #33356).
