Старая проблема с зависанием futex(), в LKM есть рецепт, как воспроизвести этот баг с xmms+jack. Ещё я заметил, что irssi в скрине стал зависать именно на вызове futex(). У меня это происходит на 2.6.18-std-smp-alt12. Steps to Reproduce: см. ссылку!
Ещё актуально?
Да.
Очень актуально, irssi виснет на футексе на 2.6.26-wks-pae.
Фигасе. Это от конфига зависит или как?
4.1 бранч irssi виснет тоже, 2.6.25-std-ll-alt8.M41.1
у меня виснет k3b-1.0.4-alt3 на ядре 2.6.27-std-def-alt11 метод воспроизведения: 1. начать копировать двд-диск. 2. k3b создает образ, 50% выполнения (вторые 50% - это запись на чистый диск скопированного). 3. открывает лоток и тут же его закрывает (с полным диском). 4. окно виснет без элементов управления (серый прямоугольник) $ strace -p 8096 -fF -o k3b-strace.log Process 8096 attached - interrupt to quit ^CProcess 8096 detached в логе одна строка: 8096 futex(0x844670c, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
Попал с psi на qt-4.5, виснет при выходе на futex на всех ядрах, включая в контейнере ovz 2.6.18. Есть исправление для этой проблемы ? Я нашёл только один старый патч http://lkml.org/lkml/2005/3/21/386 и без продолжения этой темы. Или, проблема всё-таки в userspace ?
futex нужен для того чтобы на нем виснуть. Возможно в userspace есть deadlock
В таком количестве разных юзерспейсов один плавающий дедлок?
можно выявить последовательность вызовов futexа которое заканчивается повисанием?
(В ответ на комментарий №11) > можно выявить последовательность вызовов futexа которое заканчивается > повисанием? а что, k3b у вас работает и не виснет? (см. условия в комменте #7)
У одного пользователя стабильно раз в час-два виснет firefox, сидит на branch 5.0, firefox-3.0.8, ядро 2.6.27-std-def-alt15 strace -f -p <pid> показывает 4 зависших futex
(В ответ на комментарий №13) > У одного пользователя стабильно раз в час-два виснет firefox, сидит на branch > 5.0, firefox-3.0.8, ядро 2.6.27-std-def-alt15 > > strace -f -p <pid> показывает 4 зависших futex После удаления всего профиля и импорта только закладок (никаких расширений). Подвисания стали носить другой характер - теперь очень быстрый бесконечный цикл, жрёт весь проц. [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 139823}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19914177}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 20225}, NULL) = 0 [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 20340802}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19884198}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 66618}, NULL) = 0 [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 66721114}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19896886}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 86806}, NULL) = 0 [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 86849329}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19956671}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 106945}, NULL) = 0 [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 106987948}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19957052}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 127085}, NULL) = 0 [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 127128823}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19956177}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 147298}, NULL) = 0 [pid 17100] clock_gettime(CLOCK_REALTIME, {1239789551, 147341509}) = 0 [pid 17100] futex(0xa77fefc4, FUTEX_WAIT_PRIVATE, 1, {0, 19956491}) = -1 ETIMEDOUT (Connection timed out) [pid 17100] gettimeofday({1239789551, 167531}, NULL) = 0
Это проблема неправильного юзерспейса.