Glibc, Flash ed i problemi degli utenti

Pubblicato: 12 nov 2010 da Lpt on fire!

Immagino che tutti abbiate prima o poi avuto problemi con il plugin per Flash. Recentemente molti utenti si sono accorti di un fastidioso problema all’audio durante la riproduzione audio.

Su Fedora è possibile seguire la discussione in cui si arriva a capire la causa e cosa l’ha scatenata. I messaggi sono molti, ma per riassumervi il tutto questi sono i due ingredienti del problema:

il plugin flash utilizza la funzione memcpy anche per area di memoria che si sovrappongono. In questi casi si dovrebbe usare la funzione memmove che ha un comportamento corretto a prescindere dai parametri
l’implementazione della memcpy è stata modificata per migliorarne la velocità su alcuni processori e questo ha “svelato” il problema che prima non veniva rivelato

Nella discussione generata potete trovare molti commenti interessanti con qualche intervento di Linus. Il bug relativo alla Glibc è stato chiuso come NOTABUG perché giustamente non si tratta di un bug, ma quanto ci metterà Adobe a correggere questo fastidioso problema? È corretto che i ragazzi della glibc abbandonino gli utenti a questo problema quando si potrebbe trovare facilmente una soluzione? Secondo Torvalds è inutile coinvolgere e far soffrire così gli utenti.

Se avete questo problema potete usare il codice seguente con LD_PRELOAD come workaround.

prompt$ cat > mymemcpy.c #include

void *memcpy(void *dst, const void *src, size_t size) { void *orig = dst; asm volatile(”rep ; movsq” :”=D” (dst), “=S” (src) :”0″ (dst), “1″ (src), “c” (size >> 3) :”memory”); asm volatile(”rep ; movsb” :”=D” (dst), “=S” (src) :”0″ (dst), “1″ (src), “c” (size & 7) :”memory”); return orig; } ^D prompt$ gcc -O2 -c mymemcpy.c prompt$ ld -G mymemcpy.o -o mymemcpy.so prompt$ LD_PRELOAD=mymemcpy.so /path/to/your/browser &

Via | LWN

(1 Voti | Media: 5 su 5)

23 commenti

Commenti dei lettori

(Inserisci un commento - Nascondi commenti anonimi)

Gianluca Sforna
12 nov 2010 - 10:25 - #1

0 punti

C’è un terzo ingrediente nel problema: avviene solo su macchine 64bit, in quanto la memcpy modificata è solo per questa architettura.

Per rispondere alla domanda: sì, secondo me chiudere il bug è giusto in quanto il problema è nel codice client (ovvero flash-player) ed è Adobe che dovrà risolverlo.

Per inciso, il problema era già esistente, l’unica differenza è che con la nuova glibc viene evidenziato.
groucho_nt
12 nov 2010 - 11:18 - #2

-1 punto

Da bravo (?) programmatore concordo sul fatto che non si risolvono i bug di un programma mettendo “una pezza” ad un componente esterno che non ha di fatto niente a che fare con tale programma. Specie se poi il problema è dato da un cattivo utilizzo del componente esterno.
de reditu
12 nov 2010 - 12:49 - #3

0 punti

un’altra soluzione (sia per il 32 che per il 64) non potrebbe essere usare il flash beta Square?
guiodic
12 nov 2010 - 12:53 - #4

-2 punti

Siamo all’assurdo: sono le applicazione che devono adattarsi al sistema operativo, non il contrario. Non s’è mai visto che per mettere una pezza ad un problema di un software - peraltro proprietario, e che quindi non contribuisce alla comunità - si debba introdurre un bug in una componente fondamentale del sistema.
Lo stesso Torvalds si è rifiutato un sacco di volte di “correggere” il suo kernel per far funzionare meglio programmi o librerie, per il semplice motivo che è completamente sbagliato farlo.
Invece secondo Torvalds il progetto GNU dovrebbe piegarsi all’incapacità della Adobe di scrivere software decente (tutto sappiamo quanto faccia schifo il plugin Flash su GNU/Linux).
Ragionamenti senza senso.
Conad Il Rabarbaro
12 nov 2010 - 13:21 - #5

0 punti

Io non ne posso più di Flash.
Ho un PC quad-core i7 con 8 GB di RAM e Ubuntu a 64bit, quando chiudo una tab di firefox, dove girava flash, firefox diventa grigio per 30 secondi!!!
Flash si prende il 100% di uno dei core della CPU.
sherpya
12 nov 2010 - 14:28 - #6

0 punti

si ma linus mi fa morire:

Regardless, it boils down to: we know the glibc change resulted in problems for
real users. We do _not_ know that it helped anything at all.

And in the end, the big question is simple:

Are you seriously going to do a Fedora-14 release with a known non-working
flash player?
controtendenza
12 nov 2010 - 14:39 - #7

0 punti

So che Adobe è invisa ai più, tuttavia mi trovo molto in disaccordo con le tesi da voi proposte poiché se sto sviluppando su una libreria che offre delle API, mi baso su di esse e sulla documentazione, il fatto che la libreria stessa non rispetti un “contratto”, non è imputabile a chi la utilizza.
Bisogna valutare esattamente cosa memcpy dica anche per area di memoria che si sovrappongono, non si può bollare la funzione come somma due nume e poi dire , …. si solo se sono positivi, deve essere fornita una funzione non un workaround che faccia tale opera altrimenti, resta BUG, se voi ordinate una macchina voi la usate fuori città e la macchina non funziona, venite a scoprire che la macchina funziona solo in città e se dovete andare fuori città potete utilizzare il trattore, voi siete quindi gli incapaci che dovrebbero imparare a spostrsi…… Tutto ciò non preclude il fatto che il plugin flash sotto linux non sia certo uno dei migliori codici !
sherpya
12 nov 2010 - 14:44 - #8

0 punti

si e’ un bug, ma linus ha sollevato un problema diverso, cioe’ chi ha detto che farla backward va meglio? e’ giusto rompere le cose per abilitare una memcpy che non si sa se va piu’ veloce?
kbios
12 nov 2010 - 15:50 - #9

0 punti

@7 Dalla specifica ANSI del C:

memcpy()

Syntax:
#include
void *memcpy( void *to, const void *from, size_t count );

Description:
The function memcpy() copies count characters from the array from to the array to. memcpy() returns to. The behavior of memcpy() is undefined if to and from overlap.

La funzione memmove esiste proprio per questo.
JMourinho
13 nov 2010 - 02:00 - #10

1 punto

@guidoic: evitiamo di essere prevenuti, Torwalds ha detto qualcosa di diverso, ha solo sollevato un problema reale: “se questa implementazioni non porta *reali* vantaggi, ce la sentiamo di dire agli utenti, *non potete usare flash* ?”

Possiamo fare diecimila discorsi squisitamente tecnici, per carità giustissimi, ma se non trai un vantaggio reale è giusto, almeno porsi il problema.

Questo ovviamente non deve significare “Adobe fai quello che vuoi” ma capire che all’utente, allo stato attuale, non puoi privarlo di certe applicazioni diventate, aimè, quasi essenziali.
guiodic
13 nov 2010 - 02:35 - #11

-2 punti

scusa “mou”, il problema è a monte. Come ha specificato kbios, la funzione memcpy() non è pensata per aree di memoria che si sovrappongono. Questo è un fatto noto e non solo nell’ANSI C ma anche nella documentazione di glibc.

Function: void * memcpy (void *restrict to, const void *restrict from, size_t size)

The memcpy function copies size bytes from the object beginning at from into the object beginning at to. The behavior of this function is undefined if the two arrays to and from overlap; use memmove instead if overlapping is possible.

del resto non bisogna essere dei geni per capire il motivo del perché non va usata se le due aree di memoria coincidono parzialmente…. basta aver studiato il ciclo for all’esame di programmazione I al primo anno di informatica e i vettori in algoritmi e strutture dati.
PD
13 nov 2010 - 09:51 - #12

2 punti

Che nel plugin ci sia un bug non ci piove ma… Forse che tale sovrapposizione di memoria non fosse *voluta*? Del resto il problema è saltato fuori solo quando RH ha corretto memcpy() e memcopy() per le piattaforme a 64bit, facendo copiare la memoria nel verso contrario.

PS. Di solito quando si preferisce usare memcpy() è per avere un overhead inferiore.
Pepsy
13 nov 2010 - 11:49 - #13

1 punto

@ Guiodic(commento 11)
almeno adesso spiegaci cosa del perché della tua frase riguardo puntatori e ciclo for…non è un flame sia chiaro sono realmente interessato a quella tua affermazione :D
JMourinho
13 nov 2010 - 13:53 - #14

0 punti

@guiodic: ma su questo siamo tutti d’accordo, Torwalds compreso.
Quel che volevo dire io e che lo stesso Linus ha detto è che nello specifico caso, essendo un qualcosa che deve portare dei miglioramenti all’utente finale ma che nel concreto non ne porta (lui stesso ha fatto dei test e la sua “ridicola” patch non si è mostrare inferiore come prestazioni), in questo frangente ed allo stato attuale ce la sentiamo di dire agli utenti “andate più veloci ma non potete usare Flash anche se con questa patch le prestazioni non degraderebbero”?
Come spesso gli capita, Torwalds evidenzia in maniera pragmatica un problema reale nell’utilizzo finale.
Poi va da se che questa non è un cosa tanto ortodossa e che non deve rappresentare la regola o prospettiva futura ma solo un tampone, controllato, momentaneo.
guiodic
13 nov 2010 - 14:48 - #15

-2 punti

@mourinho: fare i test su una singola patch, o magari con un singolo algoritmo è sempre piuttosto pericoloso. Bisogna vedere nel complesso questo e altri cambiamenti in un lavoro che è “in progress”.
Comunque sia, ora sia quelli di adobe, sia i distributori, sanno dove eventulmente mettere mano per aggiustare il problema. Nulla vieta che il distributore decida di tornare alla vecchia implementazione.
Comunque il bug andrebbe riportato alla adobe e bisognerebbe che si dessero una mossa.
JMourinho
13 nov 2010 - 17:20 - #16

0 punti

@guiodic: d’accordissimo!!!
bulash
13 nov 2010 - 17:57 - #17

0 punti

uso fedora ed ho questo problema che per fortuna riguarda una minoranza, seppur non bassissima, di video.

uso flash square 64bit, mi trovo direi bene a parte questo problema. (chiaramente uso html5 x youtube, ma purtroppo al di la di youtube flash domina ancora)

#3
no, square non risolve il problema!
ciclo for
13 nov 2010 - 20:32 - #18

1 punto

#11
dai faccelo tu un plugin flash pieno dei tuoi cicli for
PD
13 nov 2010 - 23:44 - #19

0 punti

Chiedo venia, nel commento #12 volevo dire memmove() non memcopy (LOL)

Ad ogni modo Torvalds ha i suoi motivi (ovviamente) per sostenere quel che dice:

- è vero che adobe ha rilasciato un plugin bacato ma, *come fanno tutti*, ha visto che la piattaforma data da gcc+glibc era fatta in un certo modo e ci si è adattata. Del resto il plugin è specifico per linux.

- In fedora questa piattaforma viene di fatto cambiata: dunque RH avrebbe dovuto prima proporre la patch in upstream in glibc, quindi magari insultare pesantemente adobe una volta rilasciata una versione corretta (ma non vedo perché, gli errori capitano molto frequentemente.)

- In Fedora queste cose accadono decisamente troppo spesso. Non è la prima volta che Torvalds (utente Fedora, ovviamente) lo fa notare.
darkcg
17 nov 2010 - 03:10 - #20

0 punti

@PD: Le “piattaforme” cambiano, sono le applicazioni a doversi adattare. La colpa non sarà di Adobe ma è comunque incombenza di Adobe aggiustare il problema. Il secondo punto è impreciso: il maintainer di glibc, nonchè quello che contribuisce piu codice è Ulrich Drepper che E’ un dipendente Red Hat. Ne consegue che quello che mettono dentro Fedora è già l’upstream di glibc (cosi come per molti altri progetti). E vero che questi problemi accadono spesso in Fedora. E anche vero però che per quello che è Fedora e per quello che si prefigge non è affatto un problema. Sono gli inconvenienti del bleeding edge ed è comunque inevitabile su una distribuzione in fortissimo sviluppo come Fedora.
Timothy Redaelli
17 nov 2010 - 22:04 - #21

0 punti

Che flash faccia schifo è risaputo, ma non pensavo che facesse COSÌ schifo.
Che ma memcpy NON si usa per aree che POTREBBERO sovrapporsi è una regola che si impara alle superiori.

Se la gente non sa programmare, non dovrebbe farlo.
guiodic
18 nov 2010 - 20:00 - #22

0 punti

Non capisco l’ironia di alcuni sul ciclo for.
La memcpy() si implementa con un for o un while, comunque con un ciclo.

Questo è un esempio: http://software.intel.com/en-us/articles/memcpy-performance/

Il codice mostrato nel post è un’ottimizzazione scritta direttamente in assembly x86 con il prefisso rep, ma sempre di ciclo si tratta. rep esegue (e)cx volte l’istruzione che segue, decrementando (e)cx … esattamente come si fa in genere con un for.

Comunque tutte queste discussioni sono possibili solo perché il codice sorgente si può vedere. Su Windows non si vede e uno si deve attenere alla documentazione, non vedo perché programmando su un s.o. open source uno debba fare diversamente.
La documentazione dice di non usare la memcpy() per aree di memoria sovrapposte? bene, quindi non si fa e basta, non ti deve fregare nulla se quelli di glibc un giorno si alzano e decidono iniziare a copiare dalla fine invece che dall’inizio. Saranno pure cavoli loro no?
ninjac
04 dic 2010 - 04:25 - #23

0 punti

Chicca: eccola senza ciclo, almeno ad alto livello :))

void *copy(void *dest, void *src, size_t size)
{

struct pippo {

char a[size];

}__attribute__((packed));

*(struct pippo *)dest = *(struct pippo *)src;

return (dest);

}