On Sat, 16 Jul 2011 17:52:15 +0200
Davide Bolcioni <db_erlug@xxxxxxxx> wrote:
> > > non ho capito cosa vorresti far fare al programma vero (non
> > > l'esempio) :)
> >
> > anche "hello world" si pianta
>
> Magari c'è qualcosa in più che non ci hai scritto, eh ?
ho cominciato con "qualsiasi cosa compilo"
> > > comunque ctime non la puoi usare dentro a un signal handler,
> > > proprio perche' fa locking e se ti arriva il segnale mentre sei
> > > dentro ctime hai perso. c'e' una spiegazione qui
> > > https://bugzilla.redhat.com/show_bug.cgi?id=152319
> >
> > bug simile, inerente ai kerbnel 2.4, risolto da eoni anni, in teoria
> > dovrebbe essere parte della storia, ma essere ben lontano dai
> > kernel 2.6
>
> Quale bug ? Se il bug è "ctime() non funziona in un signal handler"
> non è un bug, è la specifica.
> > > ltrace te lo fa vedere meglio:
> > >
> > > $ ltrace -Sf ./ctime
> >
> > [cut]
> >
> > > [pid 11148] SYS_futex(0x7fcfdba799f4, 0, 2, 0, 22
> >
> > non cambia il risultato finale, non DEVE funzionare cosi, un
> > puntatore NULL sull'array dei thread DEVE mandare in timeout il
> > thread manager e farlo tornare nello stack degli ID di thread al
> > parent più prossimo ancora attivo (risalendo, se necessario, fino
> > al kthread stesso)
>
> Se ho sbrogliato correttamente quel che dici stai parlando della
> vecchia implementazione. Però fino a che non ci scrivi dove sta il
> bug noi non possiamo che tirare a indovinare.
Se lo sapessi non sarei qua, le cose semplici le riesco a far da solo,
e' per le cosa fottutamente impossibili e aggrovigliate che busso
questa porta :D
> > PS: non percepisco bene in questo contesto l'utilità di ltrace?
> > mica mi si pianta su una chiamata alle librerie... quel che vedo è
> > la stessa cosa che vedevo già con strace...
> >
> > PPS: mi sorge il dubbio che il difetto non sia sul kernel ma nei
> > lock delle libc6, che sono state aggiornate appunto un paio di
> > settimane fa in sid :-\ (e sia ctime che printf non sono
> > async-thread-safe... e sono in libc6)
>
> Il bug segnalava come libc sotto 2.6 usasse un lock in ctime(). il
> che se vogliamo non è una bellissima cosa.
rimettendo le cose in fila, se leggi prima email ho dei FUTEX che
puntano a NULL e mi piantano ciò che compilo, codice pulito (teoria),
sintatticamente corretto, no warning, mi si pianta qualsiasi cosa che
sia sotto thread (di qualsiasi tipo, pthread, boost::thread, apr).
Pindaricamente la gestione dei thread gestita dal kernel tramite FUTEX
dovrebbe avere un sistema che dopo un tempo "x" dovrebbe killare il
thread, pulire la memoria usata dal thread terminato, tornare la
gestione al thread parent o cmq di livello superiore, e ciò non mi
avviene. Mi piacerebbe prima capire se è un errore mio (per questo ho
allegato ctime.c, per vedere se altri hanno lo stesso risultato mio),
per poi capire se è il kernel che manca di qualcosa, se libc6, o se
devo sedermi con una tanica di caffè e srotolarmi 700 e passa file .cpp
(il che porterebbe i tempi di debug a livello "mio pronipote potrebbe
vedere la fine"
lo stesso codice, compilato sotto debian stable con kernel
standardissimo, fila via liscio come l'olio, quindi escluderei
problemi nei sorci dell'applicativo.
|