Facebook corrige un bug responsable de 50 % des plantages sur iOS

Facebook corrige un bug responsable de 50 % des plantages sur iOS

On a failli attendre

Avatar de l'auteur
Sébastien Gavois

Publié dans

Société numérique

14/08/2014 2 minutes
16

Facebook corrige un bug responsable de 50 % des plantages sur iOS

Facebook vient de mettre à jour son application iOS pour iPhone et iPad avec la correction d'un bug qui traînait depuis des mois. L'équipe en charge du projet s'explique et indique que plus de 50 % des plantages devraient désormais être évités.

Le mobile est un élément incontournable pour les réseaux sociaux, y compris pour Facebook bien évidemment. Ce dernier l'a d'ailleurs compris depuis longtemps et propose des applications mobiles sur Android et iOS. Pour rappel, sur Windows Phone c'est Microsoft qui s'en charge.

 

Via un long billet sur son blog, la société de Marck Zuckerberg vient d'annoncer une nouvelle version de son application pour les terminaux Apple. Celle-ci n'apporte aucune nouvelle fonctionnalité, mais elle n'en reste pas moins importante étant donné qu'elle corrige un bug... vieux de plusieurs mois. Les développeurs indiquent que plus de 50 % des plantages de l'application devraient désormais être évités.

 

« Des mois », un temps extrêmement long pour corriger un problème qui entraînait pourtant de nombreux retours de la part des utilisateurs. Le problème étant que les développeurs ne trouvaient pas « le bon angle pour aborder ce problème ». Afin de faire amende honorable, un long billet explicatif a été mis en ligne par ici.

 

Pour télécharger Facebook pour iOS, c'est par ici que ça se passe. Notez que la mouture Android n'est pas concernée, car le souci était  lié au Core Data system d'Apple. La dernière mise à jour sur la plateforme de Google permettait de retrouver plus facilement un tri des actualités par ordre chronologique. Comme toujours, n'hésitez pas à nous faire part de vos retours via les commentaires.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Fermer

Commentaires (16)


Amnesiac
Le 14/08/2014 à 08h 25

Il était temps <img data-src=" />


Industriality
Le 14/08/2014 à 08h 27

Un dev pour nous expliquer ça en termes profane ?


maestro321
Le 14/08/2014 à 08h 36

Ha! une news par parler d’une correction d’un vieux bug de facebook.

Ca c’est du contenu! <img data-src=" />



semi-<img data-src=" />


Leynas
Le 14/08/2014 à 08h 38







Industriality a écrit :



Un dev pour nous expliquer ça en termes profane ?







Rasoir d’Occam : Apple, et encore plus iOS, c’est vraiment tout moisi. Je ne vois pas d’autre explication.



Leynas.



aureus Abonné
Le 14/08/2014 à 08h 39







Industriality a écrit :



Un dev pour nous expliquer ça en termes profane ?





J’avoue que ca m’interesse, que j’ai cliqué sur le lien, mais lire des explications de dev à 10h30 du matin je suis pas encore prêt. Si on pouvait avoir un résumé le temps que je prenne ma pause café <img data-src=" />



canti
Le 14/08/2014 à 08h 42







Industriality a écrit :



Un dev pour nous expliquer ça en termes profane ?









huuuuum ….. huuuum…. ca va pas être facile parceque c’est un peu pointu comme bug <img data-src=" />



de ce que je comprend, le coeur c’est ca



The SSL layer was writing to a socket that was already closed and subsequently reassigned to our database file



Our file descriptor retention policy looked suspect. Although SPDY used the recommended CFSocket wrapper for our database, the SSL layer did not. The SSL layer instead handled a raw file descriptor and, consequently, lifetime handling was not automatically synchronized.





de ce que je comprend, les données transitent par SPDY ( un HTTP++), et par SSL. Normalement quand le service apple (cfsocket) demande de couper la communication, plus aucune donnée ne doit arriver, mais le SSL n’était pas informé, et continuait a fonctionner, et a écrire dans un emplacement où il n’avait pas le droit d’écrire.



En gros, pour que ca tombe, il fallait que SPDY soit stoppé, et que SSL continue

alors je suis pas un dev iOS, ni web, je ne sais pas quelles conditions peuvent causer ce genre de comportement…



typhoon006 Abonné
Le 14/08/2014 à 08h 42

SPDY fermé le socket avant SSL, du coup SSL tentait d’écrire et prout corruption


Industriality
Le 14/08/2014 à 08h 43

Merci messieurs !


podpo
Le 14/08/2014 à 09h 02

C’est plus fun que ça si j’ai bien compris.

1/ Le file descriptor pour le composant SSL (en français, l’amarre du composant réseau qui fait de la communication web sécurisée) est fermé. Mais le composant SSL continue de tourner

2/ La base de données SQLite est ouverte et rattachée par hasard au même file descriptor (donc à la même “amarre”)

3/ Le composant SSL tente d’écrire dans son file descriptor, qui a été réattribué. Donc pouf corruption de la base de données.



Citations :



The SSL layer instead handled a raw file descriptor and, consequently, lifetime handling was not automatically synchronized. The SPDY socket closed before the SSL and created a race window where writes would go to a file that was “lucky enough” to receive the same file descriptor as the recently closed socket.


trash54
Le 14/08/2014 à 09h 02







maestro321 a écrit :



Ha! une news par parler d’une correction d’un vieux bug de facebook.

Ca c’est du contenu! <img data-src=" />



semi-<img data-src=" />







FB + iOs ==&gt; actu <img data-src=" />



Tetedeiench
Le 14/08/2014 à 09h 21







podpo a écrit :



C’est plus fun que ça si j’ai bien compris.

1/ Le file descriptor pour le composant SSL (en français, l’amarre du composant réseau qui fait de la communication web sécurisée) est fermé. Mais le composant SSL continue de tourner

2/ La base de données SQLite est ouverte et rattachée par hasard au même file descriptor (donc à la même “amarre”)

3/ Le composant SSL tente d’écrire dans son file descriptor, qui a été réattribué. Donc pouf corruption de la base de données.



Citations :







C’est bien ça. SSL ne savait pas que le socket était fermé, continuait a écrire dedans, et commele socket en question était réattribué ben pouf, corruption.



Ils détaillent pourquoi ils en ont chié. En gros :

* Ils ont pas réussi à trouver le moment exact où le pb a été introduit (ils ont réduit le temps où cela a été introduit à un millier de commit…)

* Il ont mis du temps avant de savoir pourquoi cela merdait, car c’était une partie pure apple (donc sans forcément de grosse trace), ils l’ont remplacé par sqllite et ont reproduit le pb (je suis pas expert, je ne sais pas trop sur ce point là) avec plus d’infos.

* Ils ont du mettre en place un honeypot pour reproduire le problème sur un fichier en particulier, blindé de sondes pour simplifier, pour identifier qui était responsable, au lieu de leur sqllite.

* Leurs sondes leur ont rapporté une série de bytes communs, ils ont donc tracé tout ce qui écrivait dans l’appli cette séquence particulière, et BAM, ils sont tombé sur SSL



Je sais pas si c’est plus clair.




nirgal76
Le 14/08/2014 à 09h 53

On a un bug sur une dll qui nous à pris des années à trouver. On ne passait pas notre temps dessus mais parfois, un pti temps de libre et hop on retournait dessus. (ça figeait l’appli, donc chiant à débugger et ça n’arrivait QUE sur l’environnement de production) Il était pas bloquant mais parfois chiant. donc là, vu parfois la complexité des applis, le délai n’est pas forcément étonnant.


Stargateur
Le 14/08/2014 à 13h 19

une vrai épopée de résolution de bug :)


Lady Komandeman
Le 14/08/2014 à 17h 13

Et le bug qui fait planter l’appli Android au démarrage ? Avant la dernière màj, ça me le faisait une fois sur deux ; maintenant, c’est bien moins fréquent, mais ça arrive encore de temps en temps…



C’est un peu chiant, ça fait planter le tél pendant presque 30 secondes. <img data-src=" />



[GSIII en 4.3, rom Samsung]


nirgal76
Le 14/08/2014 à 20h 26







Lady Komandeman a écrit :



Et le bug qui fait planter l’appli Android au démarrage ? Avant la dernière màj, ça me le faisait une fois sur deux ; maintenant, c’est bien moins fréquent, mais ça arrive encore de temps en temps…



C’est un peu chiant, ça fait planter le tél pendant presque 30 secondes. <img data-src=" />



[GSIII en 4.3, rom Samsung]





j’ai le même matos et firmware que toi et je n’ai pas ce soucis. je ne suis pas un gros utilisateur de facebook, je dois le lancer 4 ou 5 fois la semaine mais je n’ai jamais jamais eu de plantage



Lady Komandeman
Le 14/08/2014 à 21h 19







nirgal76 a écrit :



j’ai le même matos et firmware que toi et je n’ai pas ce soucis. je ne suis pas un gros utilisateur de facebook, je dois le lancer 4 ou 5 fois la semaine mais je n’ai jamais jamais eu de plantage





Bizarre. Dans ce cas, je suis p’tet le bêta-testeur involontaire d’une nouvelle feature. <img data-src=" />



Ou alors mon tél est vérolé. <img data-src=" />