Для начала было бы неплохо ссылку на пример или журнал отладки падения.

(В ответ на комментарий №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)