On Wed, Feb 23, 2005 at 12:02:03AM +0100, Jakub Bogusz wrote: > On Sat, Feb 19, 2005 at 11:06:28PM +0100, Jakub Bogusz wrote: > > On Wed, Feb 16, 2005 at 12:55:46AM +0100, Witold Krecicki wrote: > > > Przy okazji - nie wiem czy to amd64-specific, ale procesy pservera > > > zwisaja na czyms z lockowaniem zwiazanym chyba (strace pokazuje wiszenie > > > na > > > futex_costam). Nie wszystkie commity to powoduja, ale znacząca część. > > > > Nie musi być commit, wystarcza checkout. > > > > Serwer zwisa na free() w czasie obsługi sygnału podczas write(). [...] > Dwie rzeczy: > > 1. czy w ogóle można używać free() w obsłudze sygnału? > man signal nie wymienia free() wśród "funkcji bezpiecznych"... > ale write(), które przerywa sygnał, jest "bezpieczna". > Swoją drogą stos wyglądał jakby glibcowe write() też coś chciało od > alokacji pamięci... > > 2. jakby się komuś chciało napisać krótki testcase do zgłoszenia > problemu z glibc... Ja na razie nie bardzo mam kiedy. > Sytuacja jest taka: serwer przyjmuje połączenie i wysyła do gniazda dane. > Druga strona zrywa połączenie, przez co serwer dostaje SIGPIPE (lub coś > podobnego); w procedurze obsługi sygnału jest free() jakiejś struktury. > I wewnątrz tego free() następuje blokada. > Nie wiem czy to wystarczy - może zbyt duże uproszczenie do powtórzenia > błędu (w rzeczywistości procesy są dwa, spięte rurką).
Update: najwyraźniej problem dotyczy tylko libc w wersji dla nptl. Nie udało mi się powtórzyć w przypadku kiedy cvs korzysta z libc w wersji dla linuxthreads (wymuszonej przez LD_ASSUME_KERNEL=2.4.6 w cvs-pserver-scripcie). (na kilkadziesiąt prób; w przypadku nptl średnio co drugi (albo i częściej) checkout przerwany ^C kończył się zostawieniem pary zablokowanych procesów) Czyli na razie mamy workaround. -- Jakub Bogusz http://cyber.cs.net.pl/~qboosh/ _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
