[ISSUE] xorg-server-1.8.2 падает с segmentation fault
Здравствуйте!
Имеет место быть вышеописанная проблема.
Вот, скажем, только что загрузились кеды, - открываю Chromium, в строке поиска ввожу текст - иксы перезагружаются.
Снова загрузились кеды, - открываю Amarok, перематываю трек - иксы перезагружаются.
Снова загрузились кеды, - ничего не делаю, вожу туда-сюда мышкой - иксы перезагружаются.
Причем происходит это спонтанно, и раз на раз не приходится. Самый поганый вид бага.
UPD:
Ан нет. Если открыть chromium, и в строке поиска начать писать что-нибудь, главное, чтобы список с историей выпал - сразу перезагрузка иксов. И это повторяется всегда!
Остальное - через раз.
В логе имею вот что:
Backtrace: [ 1171.450] 0: /usr/bin/X (xorg_backtrace+0x35) [0x486f0d] [ 1171.450] 1: /usr/bin/X (0x400000+0x55e65) [0x455e65] [ 1171.450] 2: /lib/libpthread.so.0 (0x7fcd05cca000+0xf120) [0x7fcd05cd9120] [ 1171.450] 3: /usr/bin/X (dixLookupPrivate+0xa) [0x440bee] [ 1171.450] 4: /usr/lib64/xorg/modules/extensions/libglx.so (0x7fcd03513000+0x3497e) [0x7fcd0354797e] [ 1171.450] 5: /usr/lib64/xorg/modules/extensions/libglx.so (0x7fcd03513000+0x2d7ed) [0x7fcd035407ed] [ 1171.450] 6: /usr/bin/X (FreeResource+0xae) [0x4431fa] [ 1171.450] 7: /usr/lib64/xorg/modules/extensions/libglx.so (0x7fcd03513000+0x2b29b) [0x7fcd0353e29b] [ 1171.450] 8: /usr/lib64/xorg/modules/extensions/libglx.so (0x7fcd03513000+0x2d607) [0x7fcd03540607] [ 1171.451] 9: /usr/bin/X (0x400000+0x2d4a3) [0x42d4a3] [ 1171.451] 10: /usr/bin/X (0x400000+0x24d1e) [0x424d1e] [ 1171.451] 11: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7fcd043cabbd] [ 1171.451] 12: /usr/bin/X (0x400000+0x247f9) [0x4247f9] [ 1171.451] Segmentation fault at address 0x290 [ 1171.451] Fatal server error: [ 1171.451] Caught signal 11 (Segmentation fault). Server aborting
Полный лог
/var/log/Xorg.0.log.old
xorg-server собран с флагами -Os -march=core2 -pipe
Система ~amd64
Версии пакетов:
alex@bio ~ $ emerge -pv xorg-server xorg-x11 xf86-video-ati libdrm glibc gcc gentoo-sources These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild R ] sys-devel/gcc-4.4.4-r1 USE="fortran graphite mudflap (multilib) nls nptl openmp (-altivec) -bootstrap -build -doc (-fixed-point) -gcj -gtk (-hardened) (-libffi) -multislot (-n32) (-n64) -nocxx -nopie -nossp -objc -objc++ -objc-gc -test -vanilla" 0 kB [0] [ebuild R ] sys-libs/glibc-2.11.2 USE="gd (multilib) nls -debug -glibc-omitfp (-hardened) -profile (-selinux) -vanilla" 0 kB [0] [ebuild R ] sys-kernel/gentoo-sources-2.6.34-r2 USE="-build -deblob -symlink" 0 kB [0] [ebuild R ] x11-drivers/xf86-video-ati-6.13.1 0 kB [0] [ebuild R ] x11-base/xorg-x11-7.4-r1 0 kB [0] [ebuild R ] x11-base/xorg-server-1.8.2 USE="nptl udev xorg -dmx -doc -hal -ipv6 -kdrive -minimal -static-libs -tslib" 0 kB [1] [ebuild R ] x11-libs/libdrm-2.4.21-r1 USE="-static-libs" VIDEO_CARDS="radeon -intel -nouveau -vmware" 0 kB [1] Total: 7 packages (7 reinstalls), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [1] /var/lib/layman/x11
Подскажите, добрые люди, что можно сделать? Тут еще внезапно из портежей пропал xorg-server-1.8.0, на котором, как ни странно, все работало, причем с брутальными флагами.
Вот такая беда у меня.
UPD
ISSUE: https://bugs.freedesktop.org/show_bug.cgi?id=29251
- Для комментирования войдите или зарегистрируйтесь
может попробывать собрать с
может попробывать собрать с hal?
...
Не понимаю, как hal может влиять на это, но ... пересоберу.
По итогу отчитаюсь.
UPD
Без изменений.
В сторону 1.8 пока даже не
В сторону 1.8 пока даже не смотрю, но при x86-video-ati mesa нужна или нет? И насколько libdrm из оверлея стабилен?
(Sir) * Windows looks like an open door, but no way to go *
...
[ebuild R ] media-libs/mesa-7.8.2 USE="nptl xcb -debug (-gallium) -motif -pic (-selinux)" VIDEO_CARDS="radeon -intel -mach64 -mga -none -nouveau -r128 -radeonhd -savage -sis -svga -tdfx -via" 0 kB
Насколько стабилен libdrm, я не знаю, но на xorg-server-1.8.0 все работало без сучка и без задоринки.
Кстати, а всё же - где xorg-server-1.8.0 ?? У меня он почему-то выпилен из портежа.
покажите emerge --info как
покажите emerge --info
как правило дело в неправильных флагах оптимизации...
...
Сразу скажу - флаги у меня фееричные, громко не смеяться и пальцем не показывать.
emerge --info
НО! До 1.8.2 работало всё.
Теперь же 1.8.2 собран с флагами
-Os -march=core2 -pipe
практика показывает, что
практика показывает, что такой "фееричный" набор флагов приносит много багов... мой вам совет - выставьте обычный набор типа
CFLAGS="-O2 -march=[native|core2] -mtune=[native|core2] -fomit-frame-pointer -pipe"
, а при обновлении gcc не забывайте делатьfix_libtool_files.sh <предыдущая_версия_gcc>
, а такжеlafilefixer --justfixit
после каждого ;)P.S. только не забывайте, что после изменения CFLAGS надо пересобирать всю систему, а не отдельные пакеты ;)
emerge -av @installed --keep-going
...
Спасибо за добрый совет, но я благоразумно предпочту не трогать работающую со столь фееричными флагами уже полгода систему.
Пока что решено откатом на xorg-server-1.7.7 с тем же впечатляющим набором флагов. Полёт нормальный. О сегфолте напишу лучше во фридесктоповскую багзиллу.
И, к слову. Не хочу показаться невежливым, но, как показывает практика, объяснять баги "некошерными" флагами зачастую то же самое, что объяснять баги вмешательством Адольфа Гитлера или заговором евреев.
В том, что работающий xorg-server-1.8.0 внезапно исчез из портежей, видимо, тоже виноваты
вышеперечисленные персонажифлаги компиляции.Извините за обидный поток мыслей.
с такими флагами все работает
с такими флагами все работает до поры до времени ;) наверное, каждый гентушник через это проходит ;) вернее у каждого гентушника это проходит ))))) дело все в том, что чтобы понимать какой флаг когда применять - нужно быть программистом... если разработчиком в пакете уже используются специфичные флаги оптимизации, а вы всовываете еще и другие, то случиться может что угодно... поэтому и рекомендуется использовать общие, например, -march=core2... в этом случае компилятор и сам будет знать какие регистры и наборы команд для этого проца использовать, как выравнивать кэш и все остальное...
из своего опыта могу сказать, что пока не отказался от -O3 с кучей "фееричных" флагов, меня периодически в самый неподходящий момент мучили ошибки сегментации в самых неожиданных местах в плоть до того, что вчера прекрасно отработавшая день после обновления система, сегодня уже не грузится...
а на счет обид - ты спросил, я ответил... не нравится ответ, не используй ;) только мучиться в конечном итоге тебе )))))
...
Если отказываться от особенностей Gentoo - то зачем тогда Gentoo? Если про процесс компиляции из исходников сказать "а-та-та! не лезь! дядям виднее, как надо!", то ведь на полном праве можно и про выбор use-флагов для пакетов сказать "а-та-та! дядям виднее, что куда должно входить!", а потом и про набор софта вообще можно сказать "а-та-та! а по рукам! не трогай, дядям виднее, что должно у тебя на пк быть!" - так вот тебе и винда. Как-то неправославно получается.
Если у меня болит рука - я предпочту её лечить, или пользоваться ей в меру возможностей, а не отрубать под корень вместе со второй рукой.
просто ты еще молод и горяч
просто ты еще молод и горяч ))) и явно не понимаешь сути многих флагов ;) я всего лишь хотел сказать, что если какой-то файл исходника программистом оптимизировался под mmx, а ты принудительно выставишь использовать sse, то ничего хорошего не получишь! если ты когда-нибудь просто сравнишь быстродействие пакетов просто собранных под разные процы, то поймешь, что большего и не надо ;)
да и в твоем случае оптимизировать код "фееричными" инструкциями, когда все уже "испорчено" -Os просто глупо...
конечно, это хорошо, что ты экспериментируешь, это даст тебе благой опыт, но когда-нибудь ловля багов надоест и стабильность станет важнее граммов сорости ;) да и религия заключается несколько в других вещах (например, если внимательно приглядеться, то оооочень многие пакеты просто игнорируют заданные тобой CFLAGS =))) ), но тебе это еще только предстоит понять ))) основная идея генту в ее гибкости!
...
Убедил! :)
Theli написал(а): (например,
это баг upstream и о нём нужно сказать upstream, portage как правило сообщает об этом. Для пакетов котрые очень чувствительны к опциям компиляции ставится отдельный USE типа custom-cflags у mplayer, и при его включении выводится сообщение о том что пакет будет вести себя нестабильно и это известная проблема.
это баг upstream и о нём
filter-flag видел в ебилдах ? как бы помягше, не всякая оптимизация оптимизационно полезна, некоторая так вообше ломает логику или дает rase condition.
Особенно если подумать, что делают некоторые флаги в gcc с программой (особенно с многопоточной) при условии ее ручной оптимизации.
Прикольнее всего, когда пытаются оптимизировать код на ассемблере ( не зная про его наличие) - из этого точно ничего хорошего не выйдет.
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Да никто ничего не запрещает,
Да никто ничего не запрещает, просто бороться с неведомыми багами гораздо сложнее если стоят гоночные флаги, в большинстве случаев виноваты они. К томуже у меня возникли подозрения в осмысленности набора флагов, так как согласно http://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options как минимум -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 лишние, они входят в дефолт на x86-64 с core2
...
Если я явно включу дефолтные флаги, или продублирую один несколько раз - из-за этого будут баги? о_О
вполне возможно, т.к. эти
вполне возможно, т.к. эти математические регистры почти никогда не используются одновременно... ты просто лишил компилятор возможности выбирать какой набор где лучше и сказал использовать все и сразу, как-будто кроме перечисленного в проце еще что-то есть )))
багов от этого думается
багов от этого думается больше не станет, просто в этом случае возникает вопрос в осмысленности их набора, может ты просто понабрал всяких "крутых флагов" и всё.
совет
Нужно понимать, что указание флагов так как это сделаи Вы излишне и избыточно
это всё здорово, но стоит знать, что sse уже входит в sse2, sse2 в sse3 и т.д,т.е. аналогичная корректная запись выглядит как:
проверить можно так:
ну а вообще задавать размер кешей вручную - мощно) правда совсем не понятно зачем.
...
Спасибо! Исправлю.
Второй вопрос: почему нельзя задавать размер кэшей руками?
если они те же что и в проце
если они те же что и в проце - то gcc об этом знает сям
если они больше/меньше тех, что есть в наличии - в чем тогда смысл ?
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
...
Понял, учту. Спасибо!
l1-cache-size
Вы уверены, что gcc знает размер кэшей для случаев, кроме -march=native?
haku написал(а): это всё
а также, что все эти sse уже входят в core2
...
Флаги флагами, а вон на багзилле человек подтверждает сегфолт.
Неужто действительно sse3 виноват?
вполне, я помню в
вполне, я помню в Enlightenment 0.17 было время когда были глюки с отрисовкой, если включен sse* да и в mplayer на amd64 тоже.
...
Пересобрал мир с флагами
-Os -march=core2 -pipe
Ничего не изменилось :(
alex__ написал(а): Пересобрал
Тогда еще измени на -О2 ;).
Хотя ты, наверное, перебрал только некоторые пакеты, а надо бы весь мир!
Генту, однако! :D
...
Я на всякий случай выделю жирными буквами:
Я ж говорю, флаги, как Гитлер - абсолютное зло, которым можно оправдать любые беды.
До этого все клялись, что виноваты -mfpmath=sse и иже с ними. Убрал, пересобрал - аргументы закончились, стал виноват -Os.
К вашему сведению, -Os ничего нового не включает, он только отключает оптимизацию
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Цитата: К вашему сведению,
Вы неправильно выразились, наверное... Этот флаг не отключает оптимизацию, а оптимизирует по размеру, т.е. компилятор старается уменьшить в размере исполняемый код! А это, ИМХО, может привести к более быстрому исполнению программы (особенно больших).
По сабжу: У меня та же проблема возникла при переезде xorg-server c 1.7.7 на 1.8.2 с драйверами ati. И она действительно связана с X-ми.
ipx написал(а): Этот флаг не
вот как раз таки наоборот ;) в оптимизации есть две крайности размер и скорость исполнения и располагаются они на концах одной палки ))) например, в цикле for переход на следующую итерацию сопоставим с вызовом внешней процедуры, если компилятор развернет несколько циклов подряд (просто продублирует код), например 2, то время выполнения цикла уменьшится на ("количество изначальных итераций"/2 - 1) * "время перехода на следующую итерацию". зато размер программы увеличится на размер кода цикла ;) это только один простейший способ оптимизации из тех, что умеет компилятор ;)
в общем,
-Os
существенно снижает скорость выполнения программ ;)вздрыжнъи!
Так-то оно так, но вот сабж валится с сегфолтом и на -O2, и на -Os
Вот.
до сих пор? О_о
до сих пор? О_о
ДА!
Да, детка! До сих пор!