subj собственно. Если не выходя из сессии его перезапустить, то всё более-менее работает. hal-0.5.8.1-alt1 P.S. Я понимаю конечно, что GNOME'ры у нас в Сизифе на положении бедных родствеников, однако надо всё таки и совесть иметь :-(
А с предыдущей версией пакета (hal-0.5.7-alt4.1.1.1.1) такого не наблюдалось? Интересно, хватит ли для воспроизведения этой проблемы пакетов GNOME из Сизифа от 20070202...
С предыдущей всё было пучком :-). У меня сейчас стоит последний на 20070226 Сизифофский GNOME + gnome-power-manager + gnome-volume-manager (правда без них всё равно воспроизводится), так что если проблема не будет воспроизводиться, то я буду копаться у себя, но пока все мои попытки как-то исправить ситуацию неуспешны, максимум что я могу - это зайти в сессию, а затем ручками перезапустить haldaemon.
В общем после целого дня "траханья" с новым haldaemon'ом выяснилось, что он падает при использовании любого из двух приложений GNOME - gnome-power-manager или gnome-volume-manager (при том, что при их сборке никаких ошибок не возникает). Это два приложения, которые наиболее тесно интегрированы с HAL. Однако помимо них с HAL связаны и nautilus и nautilus-cd-burner и gnome-vfs (а следовательно и все приложения его использующие). Только ли из-за этих двух приложений может падать hald я не знаю, так как в процессе экспериментов закачал и собрал новые версии nautilus и nautilus-cd-burner (может с текущими Сизифовскими также будут проблемы) и после того, как нащупал более-менее рабочий вариант я больше экспериментировать не хочу, и так почти весь день потерял. P.S. никаких вразумительных следов hald при падении не оставляет, так что причины падений не понятны.
Вот мать твою, @$%$#%$@%$#, вроде всё нормально работало, решил попробовать запустить hal-device-manager (из пакета hal-gnome) и %$#%$#%$-тить, haldaemon опять грохнулся :-(( Короче на новый hal "дыхнуть" нельзя, чуть тронул и он в даун.
hal-device-manager отработал нормально, hald жив, падать вроде и не собирался
У меня падение hald при запуске hal-device-manager воспроизводится 100% и на std и на wks ядрах и под GNOME и под IceWM (специально сейчас закачал и поставил) :-(. Сейчас отключил от ноута все девайсы кроме внутренних и всё равно hald уходит в даун. Попробую-ка я пересобрать hal, если не поможет, то всё, я сдаюсь и иду домой :-(
Вобщем пересобрал (это я от безысходности), установил но, естественно, чуда не произошло - всё так же стабильно валится :-((. Всё, "я не доволен, я очень не доволен" и я пошел отсыпаться... P.S. что-то мне с Сизифом в последнее время катастрофически не везёт, при каждом обновлении что-нибудь да конкретно слетает :-(, причём, похоже, только у меня :-(
В общем подсоединился я к hald с помощью gdb. Результат: падает где-то в глубинах libdbus на strcmp (SIGSEGV). Точнее сказать не могу, так как вместо имён функций имею одни ?????? (за исключением strcmp). Пересборка dbus с enable-asserts и enable-checks ясности не внесла :-( Так что непонятно, кто виноват - dbus или hal.
Вот максимально "внятный" из того, чего я смог добиться, отчёт gdb: Запуск: gdb /usr/sbin/hald 3065 ... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1480112448 (LWP 3065)] 0xa7cfc521 in strcmp () from /lib/libc.so.6 (gdb) bt #0 0xa7cfc521 in strcmp () from /lib/libc.so.6 #1 0x08057d4f in ?? () #2 0x79745f67 in ?? () #3 0x08160820 in ?? () #4 0x0817e060 in ?? () #5 0x00000062 in ?? () #6 0x00000001 in ?? () #7 0x08207ea8 in ?? () #8 0x08166dd0 in ?? () #9 0x08160820 in ?? () #10 0x080898a0 in ?? () #11 0x0817cc40 in ?? () #12 0x0817e060 in ?? () #13 0x080dd740 in ?? () #14 0x080dca58 in ?? () #15 0x080dcac0 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0x08179688 in ?? () #20 0x08092a60 in ?? () #21 0xa7e17885 in dbus_message_is_error () from /usr/lib/libdbus-1.so.3 #22 0x0805cb8a in ?? () ---Type <return> to continue, or q <return> to quit--- #23 0x08078681 in _IO_stdin_used () #24 0x0807a4c0 in _IO_stdin_used () #25 0x08078681 in _IO_stdin_used () #26 0xa7e30584 in ?? () from /usr/lib/libdbus-1.so.3 #27 0xffffffff in ?? () #28 0x0815fbc0 in ?? () #29 0xafec0968 in ?? () #30 0xa7e286d0 in dbus_malloc () from /usr/lib/libdbus-1.so.3 #31 0x0805d3cb in ?? () #32 0x00000000 in ?? () #33 0x080786a9 in _IO_stdin_used () #34 0x08078702 in _IO_stdin_used () #35 0xa7e2a8ad in ?? () from /usr/lib/libdbus-1.so.3 #36 0xa7e30584 in ?? () from /usr/lib/libdbus-1.so.3 #37 0x0818e98c in ?? () #38 0xafec0a18 in ?? () #39 0xa7e2351a in dbus_watch_handle () from /usr/lib/libdbus-1.so.3 #40 0xa7e0d5bd in dbus_connection_dispatch () from /usr/lib/libdbus-1.so.3 #41 0xa7efded5 in dbus_server_setup_with_g_main () from /usr/lib/libdbus-glib-1.so.2 #42 0xa7e5b678 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #43 0xa7e5e412 in g_main_context_check () from /usr/lib/libglib-2.0.so.0 #44 0xa7e5e7bc in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 ---Type <return> to continue, or q <return> to quit--- #45 0x0805600e in ?? () #46 0x0808b4d8 in ?? () #47 0x08055840 in ?? () #48 0x08056250 in ?? () #49 0x00000000 in ?? () #50 0x080779e3 in _IO_stdin_used () #51 0x00000bf9 in ?? () #52 0x00000000 in ?? () #53 0x00000000 in ?? () #54 0x00000000 in ?? () #55 0x00000000 in ?? () #56 0xafec0fa4 in ?? () #57 0x00000001 in ?? () #58 0x00000000 in ?? () #59 0x00000000 in ?? () #60 0x00000000 in ?? () #61 0xa7c9b274 in ?? () from /lib/libc.so.6 #62 0xa7e00520 in ?? () #63 0x00000000 in ?? () #64 0x07ab9ab2 in ?? () #65 0xa7f4dfd4 in ?? () from /lib/ld-linux.so.2 #66 0xa7e00b10 in ?? () #67 0xa7c77060 in ?? () from /lib/libpthread.so.0 ---Type <return> to continue, or q <return> to quit--- #68 0xafec0c30 in ?? () #69 0xa7f42280 in _dl_fixup () from /lib/ld-linux.so.2 #70 0xa7caa05c in __libc_start_main () from /lib/libc.so.6 #71 0x0804c381 in ?? () (gdb)
После обновления до 0.5.9-alt1 вроде всё заработало
