Начиная с версии libxine-1.1.21 появились краши при проигрывании многих avi. Замечено было на kaffeine, однако таким-же образом падения замечены и на xine-ui, на тех-же файлах.
Для начала было бы неплохо ссылку на пример или журнал отладки падения.
(В ответ на комментарий №1) > Для начала было бы неплохо ссылку на пример или журнал отладки падения. Вчера как раз готовил отчёт glibc о проблемах с памятью при вызове xine, когда предыдущая проблема с kernel-3.0.35 + nvidia_glx_295.59 (27506), после вызова ufoai, привела даже к падению иксов (неполному, скорее дрова NVidia заклинило). Сегодня половлю и выделю файл с наиболее ярким проявлением этой проблемы. Заодно проверю на Сизифе.
Я отправли на сборку новый libxine. Как-минимум у меня 1 непоказывавшийся avi стал показываться.
Created attachment 5499 [details] Падение при проигрывании Тачки.2.2011 Файлы выкладывать не буду иначе с моего сервера прийдётся его грузить долго.
Created attachment 5500 [details] Падение при проигрывании Kak.priruchit.drakona.2010
Падения похожи хотя из kaffeine падение может ещё происходить в момент закрытия потока xine, причём и в TDE и в KDE4. В Сизифе падения замечаются тоже, хотя достаточно редко.
(В ответ на комментарий №4) > Файлы выкладывать не буду иначе с моего сервера прийдётся его грузить долго. На торренты ссылку можно. Из-под нового пользователя попробуйте на всякий.
(В ответ на комментарий №6) > из kaffeine падение может ещё происходить в момент закрытия C libxine > 1.1.21-alt2 ?
(В ответ на комментарий №8) > (В ответ на комментарий №6) > > из kaffeine падение может ещё происходить в момент закрытия > C libxine > 1.1.21-alt2 ? А он где? В T6 его нет.
(В ответ на комментарий №8) > (В ответ на комментарий №6) > > из kaffeine падение может ещё происходить в момент закрытия > C libxine > 1.1.21-alt2 ? Собрал 1.1.21-alt3 из Сизифа. Проблема осталась и воспроизводится у меня на двух машинах с T6. Ещё немного отчётов с падениями: ************************************************************************ ************ The.Legend.of.Korra.S01E07.www.alive-ua.com.avi *********** [roman@roman ~]$ xine This is xine (X11 gui) - a free video player v0.99.5. (c) 2000-2007 The xine Team. socket(): Address family not supported by protocol No accelerated IMDCT transform found [mpeg4 @ 0x8818ec0] header damaged *** glibc has detected an error in xine: free(): invalid pointer: 0x0895eea0 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6b9da)[0xb73e79da] /lib/libc.so.6(+0x6d313)[0xb73e9313] /lib/libc.so.6(cfree+0x71)[0xb73ec591] /usr/lib/libavutil.so.51(av_free+0x1b)[0xb58c715b] ************************************************************************ ************ Тачки.2.2011.avi ****************************************** [roman@roman ~]$ xine This is xine (X11 gui) - a free video player v0.99.5. (c) 2000-2007 The xine Team. socket(): Address family not supported by protocol No accelerated IMDCT transform found *** glibc has detected an error in xine: corrupted double-linked list: 0x081f1578 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6b9da)[0xb74169da] /lib/libc.so.6(+0x6e99e)[0xb741999e] /lib/libc.so.6(__libc_malloc+0x60)[0xb741b0c0] /lib/libc.so.6(+0x1fff8)[0xb73caff8] /lib/libc.so.6(+0x19025)[0xb73c4025] /lib/libc.so.6(+0x17a24)[0xb73c2a24] /lib/libc.so.6(iconv_open+0xcc)[0xb73c25dc] /usr/lib/libxine.so.1(+0x2aca9)[0xb7749ca9] ************************************************************************ ************ Kak.priruchit.drakona.2010.avi **************************** [roman@roman ~]$ xine This is xine (X11 gui) - a free video player v0.99.5. (c) 2000-2007 The xine Team. socket(): Address family not supported by protocol No accelerated IMDCT transform found *** glibc has detected an error in xine: free(): invalid pointer: 0xb0172938 *** ======= Backtrace: ========= /lib/libc.so.6(+0x6b9da)[0xb738f9da] /lib/libc.so.6(+0x6d313)[0xb7391313] /lib/libc.so.6(cfree+0x71)[0xb7394591] /usr/lib/libfreetype.so.6(+0x6c7d)[0xb7236c7d] /usr/lib/libfreetype.so.6(+0xbd6a)[0xb723bd6a] /usr/lib/libfreetype.so.6(FT_Remove_Module+0x10f)[0xb723f26f] /usr/lib/libfreetype.so.6(FT_Done_Library+0x140)[0xb723f9a0] /usr/lib/libfreetype.so.6(FT_Done_FreeType+0x28)[0xb72370a8] /usr/lib/libxine.so.1(+0x2c752)[0xb76c4752] В целом замечается два типа падения: почти сразу после запуска и при выходе. Повторяемость процентов 50. Падение при запуске лучше всего воспроизводится если открывать файл из меню xine, а не передавать в командной строке. Из файлов на которых хорошо воспроизводятся падения есть The.Legend.of.Korra.S01E07.www.alive-ua.com.avi, который имеет размер 300Мб, загрузить его можно здесь: http://alive-ua.com/cartoons/70867-avatar-legenda-o-korre-1-sezon-the-last-airbender-the-legend-of-korra-2012ruseng-hdtvrip.html
(В ответ на комментарий №9) > > C libxine > 1.1.21-alt2 ? > А он где? В T6 его нет. Не доехал еще, значит. Из P6 можно пока взять.
(В ответ на комментарий №10) > > > из kaffeine падение может ещё происходить в момент закрытия > > C libxine > 1.1.21-alt2 ? > Собрал 1.1.21-alt3 из Сизифа. Проблема осталась и воспроизводится у меня на > двух машинах с T6. Ещё немного отчётов с падениями: Это ж не kaffeine. P.S. С xine воспроизвел. Новый xine-ui не лечит.
(В ответ на комментарий №12) > > Собрал 1.1.21-alt3 из Сизифа. Проблема осталась и воспроизводится у меня на > > двух машинах с T6. Ещё немного отчётов с падениями: > Это ж не kaffeine. > С xine воспроизвел. Новый xine-ui не лечит. Не kaffeine, но в нём фактически то-же самое и воспроизводил на xine что-бы оторвать связь с kaffeine, а выделить первоисточник.
Ещё один момент. Повторяемость падений не 100% т.е раза с третьего-четвёртого проигрывание запускается и играет до конца, хотя затем может упасть при выходе.
Проблема по прежнему актуальна и сейчас 100% воспроизводится на одном из avi. Очередной подход к изучению проблемы показал: - пересборка пакетов libav-0.8.4-alt1, libxine-1.1.21-alt3, xine-ui-0.99.6-alt1.1 и kaffeine-0.8.8-alt8 проблемы не решает; - замечена связь проблемы с архитектурой, а именно проблема воспроизводится на x86_32, при этом на x86_64 в том-же окружении проблемы нет; - от дистрибутива T6 или Sisyphus проблема похоже не зависит, На Sisyphus-x86 падения правда не проверял; - проблема устойчиво связана с операциями на памяти, а именно двойное выделение-освобождение в библиотеке libav, функций av_malloc() и av_free(). Возник из всего этого вопрос. Какая в libav может быть зависимость от архитектуры, которая приводит к подобным проблемам на x86_32?
(В ответ на комментарий №15) > Какая в libav может быть зависимость от архитектуры Теоретически что угодно. У меня p6 из подручных только x86_64. Для начала попробуйте libav из ftp://devel.altlinux.ru/zerg/misc/M60P/p6_zerg/ Если воспроизведется, я еще обновлю там до http://packages.altlinux.org/en/Sisyphus/srpms/libav
(В ответ на комментарий №16) > У меня p6 из подручных только x86_64. > Для начала попробуйте libav из ftp://devel.altlinux.ru/zerg/misc/M60P/p6_zerg/ Этот без изменений. > Если воспроизведется, я еще обновлю там до > http://packages.altlinux.org/en/Sisyphus/srpms/libav До этого я и сам обновлял, см. комментарий №15 Попробовал --disable-memalign-hack и теперь не падает, хоть при запуске, полностью играется, а затем падает при выходе. Попробую жестко выбрать тип memalign или отключить его вообще.
(В ответ на комментарий №17) > Попробовал --disable-memalign-hack и теперь не падает, хоть при запуске, А в libav-0.8.4 он отключен по умолчанию. Погоняю его и в p6, наверное, отправлю.
(В ответ на комментарий №18) > (В ответ на комментарий №17) > > Попробовал --disable-memalign-hack и теперь не падает, хоть при запуске, > А в libav-0.8.4 он отключен по умолчанию. Погоняю его и в p6, наверное, > отправлю. Моя ошибка, как раз я включил этот параметр --enable-memalign-hack. Остальное по простому там не проверишь.
Valgrind по этому поводу сообщает такое: ==11648== Thread 6: ==11648== Invalid read of size 4 ==11648== at 0xAA299A1: pp_postprocess (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x72dc2c5 is 965 bytes inside a block of size 967 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== ==11648== Invalid read of size 4 ==11648== at 0xAA29990: pp_postprocess (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x72dc2c9 is 2 bytes after a block of size 967 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== ==11648== Invalid write of size 4 ==11648== at 0xAA29999: pp_postprocess (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x7b5143c is 892 bytes inside a block of size 893 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== ==11648== Invalid read of size 1 ==11648== at 0xAA0F768: ??? (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x72dc2c7 is 0 bytes after a block of size 967 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== ==11648== Invalid read of size 1 ==11648== at 0xAA0F75C: ??? (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x7b5143d is 0 bytes after a block of size 893 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== ==11648== Invalid read of size 1 ==11648== at 0xAA0ECEE: ??? (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x72dc2c7 is 0 bytes after a block of size 967 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== ==11648== Invalid read of size 1 ==11648== at 0xAA0ECEA: ??? (in /usr/lib/libpostproc.so.52.0.0) ==11648== Address 0x7b5143d is 0 bytes after a block of size 893 alloc'd ==11648== at 0x4027440: memalign (vg_replace_malloc.c:581) ==11648== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==11648== by 0x80290EC: av_malloc (in /usr/lib/libavutil.so.51.22.1) ==11648== Что при определённых обстоятельствах и разбивке памяти вполне может вызывать проблемы. Я вот только не пойму. Это pp_postprocess() лезет за границу выделенной памяти или memalign() некорректно выделяет. Кстати это объясняет почему --enable-memalign-hack несколько смягчает проблему, покольку образ выделения памяти меняется и вылезание за её границы не сразу вызывает падение.
(В ответ на комментарий №20) > Valgrind по этому поводу сообщает такое: Детализировал, установив пакеты с отладочной информацией. В целом замечены два типа ошибки обращения к памяти: ==27561== Invalid write of size 4 ==27561== at 0xAA29999: pp_postprocess (postprocess.c:1031) ==27561== by 0x7FEB511: ff_decode_data (ff_video_decoder.c:1598) ==27561== by 0x7DA14FA: video_decoder_loop (video_decoder.c:414) ==27561== by 0x4CC894F: start_thread (pthread_create.c:297) ==27561== by 0x59B753D: clone (clone.S:130) ==27561== Address 0x7b51ffc is 892 bytes inside a block of size 893 alloc'd ==27561== at 0x4027440: memalign (vg_replace_malloc.c:581) ==27561== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==27561== by 0x80290EC: av_malloc (mem.c:83) ==27561== by 0x80291C5: av_mallocz (mem.c:156) ==27561== by 0xAA099A7: reallocBuffers (postprocess.c:893) ==27561== by 0xAA29606: pp_get_context (postprocess.c:945) ==27561== by 0x7FEA5D9: pp_change_quality (ff_video_decoder.c:508) ==27561== by 0x7FEBB60: ff_decode_data (ff_video_decoder.c:560) ==27561== by 0x7DA14FA: video_decoder_loop (video_decoder.c:414) ==27561== by 0x4CC894F: start_thread (pthread_create.c:297) ==27561== by 0x59B753D: clone (clone.S:130) ==27561== Invalid read of size 1 ==27561== at 0xAA0F768: postProcess_MMX2 (postprocess_template.c:3403) ==27561== by 0xAA29F85: pp_postprocess (postprocess.c:632) ==27561== by 0x7FEB511: ff_decode_data (ff_video_decoder.c:1598) ==27561== by 0x7DA14FA: video_decoder_loop (video_decoder.c:414) ==27561== by 0x4CC894F: start_thread (pthread_create.c:297) ==27561== by 0x59B753D: clone (clone.S:130) ==27561== Address 0x72dce87 is 0 bytes after a block of size 967 alloc'd ==27561== at 0x4027440: memalign (vg_replace_malloc.c:581) ==27561== by 0x40274FE: posix_memalign (vg_replace_malloc.c:709) ==27561== by 0x80290EC: av_malloc (mem.c:83) ==27561== by 0x80291C5: av_mallocz (mem.c:156) ==27561== by 0xA195E71: ff_alloc_picture (mpegvideo.c:333) ==27561== by 0xA198090: MPV_frame_start (mpegvideo.c:1221) ==27561== by 0x9FA21D1: ff_h263_decode_frame (h263dec.c:628) ==27561== by 0xA269018: avcodec_decode_video2 (utils.c:1152) ==27561== by 0x7FEB264: ff_decode_data (ff_video_decoder.c:1474) ==27561== by 0x7DA14FA: video_decoder_loop (video_decoder.c:414) ==27561== by 0x4CC894F: start_thread (pthread_create.c:297) ==27561== by 0x59B753D: clone (clone.S:130) Однако оба типа характеризуются вычислением размера участка памяти в ff_alloc_picture (mpegvideo.c:333) или изменением размера pp_change_quality (ff_video_decoder.c:508) с последующим общим выходом за размер буфера в ff_decode_data (ff_video_decoder.c:1598)
И кстати, это всё в libxine!
Открыл багу на xine-project.org: https://bugs.xine-project.org/show_bug.cgi?id=491
Created attachment 5767 [details] Обход проблемы доступа за границу выделенной памяти Данный патч обходит проблему доступа за границу выделенной памяти в ffmpeg, путём выделения на 10% больше памяти, указанием большего размера изображения. С этим патчем у меня падений нет нигде, хотя там есть ещё одно место обращения за границу памяти, но это только чтение и таким-же образом это не обходится.
Приложу его тогда.
(В ответ на комментарий №25) > Приложу его тогда. Можно за одно обновить из репозитория, для ветки 1.1. Там ещё были некоторые исправления, после релиза 1.1.21, которые однако этой проблемы не исправляли.
(В ответ на комментарий №26) > Можно за одно обновить из репозитория, для ветки 1.1 Ок, только уже следующим таском. Уже собирается.
libxine-1.1.21-alt5 -> sisyphus: * Mon Mar 11 2013 Sergey V Turchin <zerg@altlinux> 1.1.21-alt5 - add woraround against crash; thanks rom_as@alt (ALT#27505)
