Summary: | Не работает на ядре un-def: segfault at 38 ip b75513ec sp bf9e4480 error 6 in libopenobex.so.1.4.1[b754c000+8000] | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Sisyphus | Reporter: | Motsyo Gennadi <drool> | ||||||
Component: | libopenobex | Assignee: | Valery Inozemtsev <shrek> | ||||||
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus | ||||||
Severity: | critical | ||||||||
Priority: | P3 | CC: | aris, boyarsh, cas, grizlik78, ldv, mike, shaba, shrek, vsu | ||||||
Version: | unstable | ||||||||
Hardware: | all | ||||||||
OS: | Linux | ||||||||
Attachments: |
|
Description
Motsyo Gennadi
2012-06-26 10:30:53 MSK
Обновил ядро до uname -r 3.4.3-un-def-alt0.M60P.1 Картина та же. Created attachment 5498 [details]
DIFF между /boot/config-* ядра, в котором работает (std-def) и нерабочим (un-def)
На всякий случай прикладываю DIFF между /boot/config-* ядра, в котором работает (std-def) и нерабочим (un-def)
Странно, по блютусной части разница "не в пользу" работающего ядра: --- boot/config-3.0.35-std-def-alt0.M60P.1 +++ boot/config-3.4.3-un-def-alt0.M60P.1 -CONFIG_BT_L2CAP=y -CONFIG_BT_SCO=y Есть ли возможность проверить 3.0.x-un-def из сизифного архива? (В ответ на комментарий №3) > Есть ли возможность проверить 3.0.x-un-def из сизифного архива? К сожалению нет, т.к. на этом ядре у меня не запустится графика. Сегодня попробовал в сизифе. Ядро не самое свежее: $ uname -mr 3.4.2-std-def-alt1 i686 Ситуация та же, маленький файл проскочил, а те что чуть побольше: $ dmesg | grep obex [374200.180870] obex-data-serve[8353]: segfault at 38 ip b75ad3ec sp bff4f190 error 6 in libopenobex.so.1.4.1[b75a8000+8000] [374279.888417] obex-data-serve[9050]: segfault at 38 ip b75793ec sp bf9a5f90 error 6 in libopenobex.so.1.4.1[b7574000+8000] Только вот обновил ядро, перезагрузился, и пока не могу воспроизвести ни с новым ядром, ни с предыдущим. Правда эксперимент нельзя считать чистым. До обновления ядра использовался телефон Sony Ericcsson J10i2, а после SE W810i. Как только J10i2 снова попадёт в мои лапы — проверю с ним ещё раз. В общем действительно, с SE J10i2 воспроизводится стабильно и с новым ядром. Created attachment 5501 [details]
GDB backtrace для obex-data-server
uname -r 3.4.6-un-def-alt0.M60P.1 Ситуация не исправилась. Я сейчас испробовал libopenobex версии 1.6. С моим телефоном работа починилась, так что прошу обновить. Правда приходится чинить ещё, как-минимум, сборку obex-data-server. (В ответ на комментарий №11) > Я сейчас испробовал libopenobex версии 1.6. С моим телефоном работа починилась, > так что прошу обновить. Правда приходится чинить ещё, как-минимум, сборку > obex-data-server. А можно src.rpm этих пакетов? (В ответ на комментарий №12) > А можно src.rpm этих пакетов? Собрал сам - починилось, работает, файлы кидаются. Шрек, чё делать бум? Обновленная libopenobex: http://git.altlinux.org/people/drool/packages/libopenobex.git Исправленный для сборки с этой версией obex-data-server: http://git.altlinux.org/people/drool/packages/obex-data-server.git 2 Shrek: NMU дашь на libopenobex или самому просить в devel@ ? (In reply to comment #14) > Обновленная libopenobex: > http://git.altlinux.org/people/drool/packages/libopenobex.git Поскольку вы полностью изменили структуру git-репозитория, и вместо того, чтобы смержить 1.6 (или более подходящий коммит) из git://gitorious.org/openobex/mainline.git, фактически ликвидировали преемственность, заменив весь прежний исходный код на openobex-1.6-Source, я такой NMU одобрить не могу. Что за бред? Был взят оригинальный тарбол с исходниками с оффсайта, а преемственность полностью сохранена с git-ом текущего мантейнера, что является обязательным для прохождения пакета через сборочницу. (In reply to comment #16) > Что за бред? Был взят оригинальный тарбол с исходниками с оффсайта, а > преемственность полностью сохранена с git-ом текущего мантейнера, что является > обязательным для прохождения пакета через сборочницу. У текущего мейнтейнера libopenobex.git устроен совершенно иначе: там в 1.5-alt3 находится не "оригинальный тарбол с исходниками с оффсайта", а мерж локальных изменений с тэгом 1.5 из git://gitorious.org/openobex/mainline.git Если текущего мейнтейнера libopenobex судьба этого пакета не интересует, то было бы честнее вам стать новым мейнтейнером и залить srpm, потому что фактической преемственности между вашим коммитом и 1.5-alt3 нет, а история пакета в git вас, судя по всему, не очень интересует. Кажется, текущий мантейнер наконец узнал об этой баге. Что скажет он? Надеюсь, в t6/p6 это попадет? (В ответ на комментарий №20) > Надеюсь, в t6/p6 это попадет? Хех. Оно что-то и в сизиф не попадает. Воз и ныне там... (In reply to comment #21) > (В ответ на комментарий №20) > > Надеюсь, в t6/p6 это попадет? > > Хех. Оно что-то и в сизиф не попадает. Воз и ныне там... Чтобы новая версия libopenobex попала в Сизиф, нужно нечто большее, чем сборка новой версии libopenobex: http://lists.altlinux.org/pipermail/sisyphus-incominger/2012-August/320553.html obex-data-server, исправленный для сборки с этой либой лежит у меня в git-е, как я указывал. Других нестыковок у меня локально на симпли не вылезло. Какие еще пакеты требуют пересборки/починки? По ссылке всё сказано. Я надеялся добраться, но пока не успеваю никак. Озадачишься? (В ответ на комментарий №24) > Озадачишься? Отпуск закончился, так что тоже - по возможности :) P.S. А вообще-то, такое впечатление, что блютуз в альте никому не нужен... отправлено в сизиф. Спасибо!! (В ответ на комментарий №26) > отправлено в сизиф. Ой! А в p6/t6 осталось сломанным. Можно и там исправить? это без меня :) Переоткрываю на t6. Хотя это нужно и в p6. Не надо исправленное мотать туда-сюда и переоткрывать. Эта бага -- закрыта. По бранчу открой другую. Иначе можно было бы повесить на сизиф один вечный баг обо всём и ни о чём. |