problem albo cvs albo u mnie

[Jakub Bogusz]

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/