On Fri, Jul 01, 2011 at 05:20:07PM +0200, Jakub Bogusz wrote: > On Fri, Jul 01, 2011 at 08:33:11AM +0200, Jacek Osiecki wrote: > > On Wed, 29 Jun 2011, Pawel Sikora wrote: > > > > > On Wednesday 29 of June 2011 12:10:27 Jacek Osiecki wrote: > > >> On Wed, 29 Jun 2011, Pawel Sikora wrote: > > >>> On Wednesday 29 of June 2011 11:52:46 Jacek Osiecki wrote: > > >>>> Pozwolę sobie więc wrzucić końcówkę z gdb: > > >>>> (gdb) bt > > >>>> #0 0x000074b5880c8243 in select () from /lib64/libc.so.6 > > >>>> #1 0x000074b575680119 in ?? () from /lib64/libgcrypt.so.11 > > >>>> #2 0x000074b57567d630 in ?? () from /lib64/libgcrypt.so.11 > > >>>> #3 0x000074b57567e914 in ?? () from /lib64/libgcrypt.so.11 > > >>>> #4 0x000074b57567d9bf in ?? () from /lib64/libgcrypt.so.11 > > >>> > > >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ doinstaluj jeszcze pakiety > > >>> -debuginfo, t obedzie cos wiecej widac. > > >> No tego właśnie się obawiałem ;) > > >> Zobaczymy - jeśli po tych upgrade'ach które zrobiłem problem nie wystąpi, > > >> to sprawa zamknięta. Jeśli wystąpi, to zainstaluję debuginfo i się > > >> zobaczy > > >> co z tego wyniknie. > > > > No i znowu było bum, mimo wszelkich upgrade'ów... Tym razem były pakiety > > debuginfo. chyba jednak nie php jest winne... a może się mylę? > > > > Loaded symbols for /usr/lib64/php/zlib.so > > 0x0000666af9bda430 in __write_nocancel () at > > ../sysdeps/unix/syscall-template.S:82 > > 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) > > (gdb) catch syscall select > > Catchpoint 1 (syscall 'select' [23]) > > (gdb) continue > > Continuing. > > > > Catchpoint 1 (call to syscall 'select'), 0x0000666af9be1b23 in > > __select_nocancel () at ../sysdeps/unix/syscall-template.S:82 > > 82 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) > > (gdb) bt > > #0 0x0000666af9be1b23 in __select_nocancel () at > > ../sysdeps/unix/syscall-template.S:82 > > #1 0x0000666ae6d6bdcf in _gcry_rndlinux_gather_random (add=0x666ae6d69700 > > <add_randomness>, origin=RANDOM_ORIGIN_SLOWPOLL, length=120, > > level=<value optimized out>) at rndlinux.c:133 > > No to błąd do zgłoszenia w libgcrypt: przy tworzeniu zbioru dla select() > nie ma sprawdzenia, czy otrzymany deskryptor nie przekracza FD_SETSIZE. > Czyli mamy przepełnienie zmiennej na stosie. W przypadku kiedy > deskryptor nieznacznie przekracza FD_SETSIZE (=1024 normalnie), to > nadpisuje zmienną zawierającą timeout (ewentualnie zmiana tej zmiennej > zmienia wartość tego, co potem select() ze zbyt dużym pierwszym > parametrem uważa za fdset). > Tak w ogóle to zamiast select()a tam powinien być poll() i by nie było > problemu. Deskryptor jest jeden, więc nie ma sensu używanie epolla. > > Swoją drogą to ciekawe, ile jeszcze bibliotek korzysta z select()a, > przez co ma podobne problemy w przypadku przekroczenia 1024 > deskryptorów w ramach procesu... apache+php tworzy środowisko podatne na > takie błędy. > > Doraźnie - zapewne uruchamianie php via fcgi albo wyłączenie curla > by problem wyeliminowało.
Spróbuj uaktualnić libgcrypt do wersji 1.5.0-1 z CVS-u. -- Jakub Bogusz http://qboosh.pl/ _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl