problem albo cvs albo u mnie

[Jakub Bogusz]

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().
> 
> Nie mam pewności, ale może pomóc uaktualnienie glibc - z changeloga
> sprzed wydania 2.3.4:
> 
> 2004-12-10  Ulrich Drepper  <drepper w redhat.com>
> 
>         * malloc/arena.c (arena_get2): Prevent endless loop if arenas and
>         list lock are taken.

Najwyraźniej nie pomogło. Widocznie to jakiś podobny, ale nie ten
przypadek.
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ą).


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/