glibc+nvidia: BUG? Проверьте у себя, пожалуйста.

>loating Point Exception по крайней мере в двух программах: в gimp

у megabaks была подобная проблема

а вообще на 2.12.1 достаточно много ругаются в федориной багзилле

https://bugzilla.redhat.com

проблема так и осталась )
но только на десктопе - на нетбуке норм
дело не в глибц точно
да и похоже не в блобе
т.к. после одного из обновлений (глибц в том числе) гимп завёлся
но после пересборки гимпа(сам хз зачем%)) опять отвалился
похоже косячит какая-то другая зависимость

мне кажется что дело в glibc, на нее (2.12.х) много жалоб на некорректную работу функций (см федорину багзиллу)

как вариант можно попробовать откатить glibc и посмотреть не пропадет ли бага (если конечно софт уже не нацеплял функций @GLIBC_2.12)

уже нацеплял - поэтому откатываться ой как не хоца =)

eglibc 2.11.2, драйверы 256.53. полёт нормальный.

>glibc 2.12.1

А зачем? У меня тонны ~arch пакетов, но никто не требует ~arch glibc. Сижу на 2.11.2-r3

nvidia-drivers 260.19

Опять же, что там в замаскированных такого, чего нет в ~arch? Масса приключений? :)

x11-drivers/nvidia-drivers-256.53 и никаких проблем, ни с gimp'ом, ни с amarok'ом, ни с чем-нибудь ещё.

>А зачем?
за тем что бы потом у тебя было:

никаких проблем, ни с gimp'ом, ни с amarok'ом, ни с чем-нибудь ещё.

Всё. Понял :) Спасибо! :D

мм... а вот это уже забавно

~ :$gimp
Floating point exception


~ :$/lib/libc.so.6 |grep -e release -e CC
GNU C Library (/MEYA ARGENTA/) stable release version 2.11.2, by Roland McGrath et al.
Compiled by GNU CC version 4.5.2.


а всего то обновила nvidia-drivers
NVRM: loading NVIDIA UNIX x86 Kernel Module 260.19.12 Fri Oct 8 13:22:24 PDT 2010

Glibc конечно пинать сейчас стало модно, но проблема то как раз не в Glibc
у меня eglibc 2.11.2

Core was generated by `gimp'.
Program terminated with signal 8, Arithmetic exception.
#0 0xb7773caf in ?? () from /lib/ld-linux.so.2
(gdb) bt
#0 0xb7773caf in ?? () from /lib/ld-linux.so.2
#1 0xb77741ea in ?? () from /lib/ld-linux.so.2
#2 0xb7775f4f in ?? () from /lib/ld-linux.so.2
#3 0xb777e526 in ?? () from /lib/ld-linux.so.2
#4 0xb7779910 in ?? () from /lib/ld-linux.so.2
#5 0xb6803b53 in ?? () from /lib/libdl.so.2

PS: простите за неинформативный backtrace,
-fomit-frame-pointer, как уж он есть

http://bugs.gentoo.org/buglist.cgi?quicksearch=nvidia-drivers

баг нужно писать на nvidia-drivers
тут еще нет ничего по этому поводу,
если что - у меня
gimp 2.7.1
glibc (у меня не с портежа) - eglibc 2.11.2-7 (debian sid sources)
остальное ~x86 (xorg-server 1.9.2)

> А зачем? У меня тонны ~arch пакетов, но никто не требует ~arch glibc. Сижу на 2.11.2-r3

Опять же, что там в замаскированных такого, чего нет в ~arch? Масса приключений? :)

Ну у меня как-то исторически оно было размаскировано. Вот теперь получил баг, убрал. А с философской точки зрения, ну надо кому-то ж тестировать всё это! :-)

К сожаению у меня тоже -fomit-frame-pointer, в glibc тоже (USE +glibc-omitfp).

Пока не нашёл возможную причину, пускал гимр с помощью gdb, если было нужно :-) такой вот изврат.

у меня тоже в gdb запускалась и megabaks тоже пробовал и gdb и strace, там работало (поначалу? сам уточнит) сейчас я корку словила простым запуском

ulimit -c unlimited
gimp
gdb /usr/bin/gimp core


но glibc тут точно непричем, если у меня с 2.11.2 то же самое вышло.

А что, собственно, надо делать с гимпом, чтобы возникла ошибка? Потыкал разные кнопочки - никаких ошибок, в консоли чисто. gentoo ~amd64, gcc 4.4.5, nvidia 260.19.12, gimp 2.6.11.

если что то по bt видно что ловится в районе libdl, вероятно что dlopen() на libGL или что-то другое от NVIDIA

тут три библиотеки ( версию я уже откатила )

libGL.so.1 => /usr/lib/opengl/nvidia/lib/libGL.so.1 (0xb67f4000)
libnvidia-tls.so.256.53 => /usr/lib/opengl/nvidia/lib/libnvidia-tls.so.256.53 (0xb678c000)
libnvidia-glcore.so.256.53 => /usr/lib/libnvidia-glcore.so.256.53 (0xb525e000)

и сейчас работает
с той лишь разницей, что сейчас No stack.

> ~amd64

спасибо, вероятно не воспроизводится на 64 битах

ничего не надо делать
это при попытке запустить
и да - где версия глибц?
да и не x86 это

костыли это все хорошо, кто в багзиллу багу пишет на nvidia-drivers ? :)

>кто в багзиллу багу пишет на nvidia-drivers ? :)
уступаю даме )

> и да - где версия глибц? 2.12.1-r3

Да, на всякий случай: CFLAGS="-march=native -O2 -pipe".

кстати в OpenSUSE KDE падает с такой же же FP exception

http://www.nvnews.net/vbulletin/showthread.php?t=156698
http://forums.opensuse.org/english/get-help-here/applications/448653-nvidia-2...
https://bugzilla.novell.com/show_bug.cgi?id=648718

спасибо за галантность, но я со своей eglibc с дебиана и gcc с gcc.gnu.org лучше допишусь в комментарии.

Вот выхдлоп валгринда: похоже там где-то переполнение:

gimp:

vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x2E 0xF
==18656== valgrind: Unrecognised instruction at address 0x4b832e5.
==18656== Your program just tried to execute an instruction that Valgrind
==18656== did not recognise.  There are two possible reasons for this.
==18656== 1. Your program has a bug and erroneously jumped to a non-code
==18656==    location.  If you are running Memcheck and you just saw a
==18656==    warning about a bad jump, it's probably your program's fault.
==18656== 2. The instruction is legitimate but Valgrind doesn't handle it,
==18656==    i.e. it's Valgrind's fault.  If you think this is the case or
==18656==    you are not sure, please let us know and we'll try to fix it.
==18656== Either way, Valgrind will now raise a SIGILL signal which will
==18656== probably kill your program.
==18656== 
==18656== Process terminating with default action of signal 4 (SIGILL)
==18656==  Illegal opcode at address 0x4B832E5
==18656==    at 0x4B832E5: ??? (in /lib/libc-2.12.1.so)
==18656==    by 0x61C2C97: ??? (in /usr/lib/libnvidia-glcore.so.260.19.12)
--18656-- REDIR: 0x4acab30 (free) redirected to 0x4026ce5 (free)

amarok:

vex x86->IR: unhandled instruction bytes: 0x66 0x66 0x2E 0xF
==18729== valgrind: Unrecognised instruction at address 0x60bf2e5.
==18729== Your program just tried to execute an instruction that Valgrind
==18729== did not recognise.  There are two possible reasons for this.
==18729== 1. Your program has a bug and erroneously jumped to a non-code
==18729==    location.  If you are running Memcheck and you just saw a
==18729==    warning about a bad jump, it's probably your program's fault.
==18729== 2. The instruction is legitimate but Valgrind doesn't handle it,
==18729==    i.e. it's Valgrind's fault.  If you think this is the case or
==18729==    you are not sure, please let us know and we'll try to fix it.
==18729== Either way, Valgrind will now raise a SIGILL signal which will
==18729== probably kill your program.
==18729== 
==18729== Process terminating with default action of signal 4 (SIGILL)
==18729==  Illegal opcode at address 0x60BF2E5
==18729==    at 0x60BF2E5: ??? (in /lib/libc-2.12.1.so)
==18729==    by 0xAD91C97: ??? (in /usr/lib/libnvidia-glcore.so.260.19.12)
--18729-- REDIR: 0x6006b30 (free) redirected to 0x4026ce5 (free)
==18729== Invalid free() / delete / delete[]
==18729==    at 0x4026D4E: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==18729==    by 0x60CE51B: ??? (in /lib/libc-2.12.1.so)
==18729==  Address 0x63238f0 is not stack'd, malloc'd or (recently) free'd

> костыли это все хорошо, кто в багзиллу багу пишет на nvidia-drivers ? :)

С утра накатаю, сейчас уже сил нет.

либо оставляем пока все на откуп коллегам из багзиллы Novell , а также с учетом других проблем (
[260.19.12 regression] Clock changes don't work (Multi-page thread 1 2 3)
260.19.12 black screen on GTX 465, Ubuntu 10.04 64
[260.19.12 regression] Tool Paletter demo from gtk-demo crashes X server (F14 i686)
Go to first new post [260.19.12] GTK Xorg 1.9 performance regressions
)

откатываем nvidia-drivers и ждем ( с нетерпением ) следующего релиза, и если gimp опять рухнет - то вперед в багзиллу и на форум нвидии.

btw, xorg-server у меня 1.7.7-r1 но я думаю это никак не влияет.

таки блоб
загрузился с 35-м ядром и 256.53 блобом - всё работает

если что то у меня
$uname -r
2.6.32.25-lu

так что ядро я не меняла, с 256.53 проблем нет , 260.19.12 дает FPE

ну ядро поменял из-за того что 36-е не хочет <260 блоба

2.6.36-gentoo x86_64
CFLAGS="-O2 -march=native -pipe"

sys-devel/gcc 4.5.1
sys-libs/glibc 2.12.1-r3
x11-base/xorg-server 1.9.2
x11-drivers/nvidia-drivers 260.19.21
media-gfx/gimp 2.6.11

гимп запустился.
правда заметил небольшую (?) разницу в температуре карточки по сравнению с пред. версией драйверов, ниже вроде стала в 3D.

а вообще на 2.12.1 достаточно много ругаются в федориной багзилле

Есть такое дело. До релиза не пробовал, в день релиза оюнаружил странную вещь: одно и то же железо, одна и та же сетевая установка, но ядерный модуль странно и рандомно цеплялся и не цеплялся. Есть мнение, что это в rpmfusion начудили.

ПС: да, с офсайта драйвер ставился без проблем в 100 случаях из 100.

[sanja@diego ~]$ lsb_release -sirc && rpm -qa glibc && glxinfo|grep -i open
Fedora 14 Laughlin
glibc-2.12.90-18.i686
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce 6600/AGP/SSE2
OpenGL version string: 2.1.2 NVIDIA 260.19.12
OpenGL shading language version string: 1.20 NVIDIA via Cg compiler

На amd64 воспроизвести не смог, но (учитывая написанное выше) вероятно что-то похожее должно быть при запуске wine. Вечером попробую.

Это баг в драйверах.
http://www.nvnews.net/vbulletin/showthread.php?t=156665
например.

PS:
sys-libs/glibc-2.12.1-r1
x11-drivers/nvidia-drivers-260.19.12

пикаса, гуглеземля, вайн
На 64 битах бага нет.

http://www.linux.org.ru/news/hardware/5554633

есть желающие потестить на 260.19.21 ? :)

НЕ бета кстати.

На amd64 бага нет, сейчас обновил )

на amd64 его и не было ;)

NVRM: loading NVIDIA UNIX x86 Kernel Module 260.19.21 Thu Nov 4 20:24:24 PDT 2010
----

~ :$gimp
Floating point exception
~ :$gimp
Floating point exception
~ :$gimp
Floating point exception


баг остался.

А баг с «уменьшением» монитора на amd hd4570 на .36 и новее у кого-то проявляется?

Баг не воспроизводится, arch linux i686, nvidia 260.19.21, glibc 2.12.1-4, gimp 2.7.1 (dev), amarok из git-20101108. Раньше бага тоже не было.

Кстати, да, ни у кого после обновлений glibc падает vbox вместе со всей системой во время работы виртуальной машины? ЕМНИП, это началось после исправления последних уязвимостей, поначалу vbox просто не запускался, со временем он таки запустился, но работает крайне нестабильно и падает, унося с собой всю систему.

$ pacman -Q glibc
glibc 2.12.1-4
$ pacman -Q nvidia
nvidia 260.19.21-2
$ uname -m
i686
$ amarok
<...>
amarok:  ********************************************************************************************** 
amarok:  ** AMAROK WAS STARTED IN NORMAL MODE. IF YOU WANT TO SEE DEBUGGING INFORMATION, PLEASE USE: ** 
amarok:  ** amarok --debug                                                                           ** 
amarok:  **********************************************************************************************
$ echo $?
0
$ gimp
$ echo $?
0

//wbr, madgnu