> En fait, je me demandais si c'était le master unicorn ou un de ses workers qui segfaultait
Clairement le worker, pas le master unicorn. Le 19 mars 2015 14:21, Florian Dutey <fdu...@gmail.com> a écrit : > > Qu'as tu changé dans tes tests pour les « faire apparaitre » ? > > J'ai lance manuellement unicorn pour voir les logs des workers dans mon > terminal et ne rien louper > > > C'est bien le même ruby utilisé dans les deux cas ? Compilé de la même > façon et sur la même plateforme ? > > rvm install 2.2.1. > Cependant, en local nous sommes sur mac, en prod / staging nous sommes sur > Docker hoste sur du amazon EC2 (centOS) > > > As-tu également du code C dans cette appli ? Cela pourrait être un > > appel free() ou similaire erroné côté C, qui est appliqué sur un autre > > pointeur que celui souhaité. Ou alors le GC détruit légitimement un > > objet, mais c'est la fonction qu'on a spécifié pour nettoyer l'objet > > (si free() ne convient pas) qui fait quelque chose d'incorrect. > > Non. Le seul code C provient de gems (sanitize, nokogiri, Oj ...) > > > Pas vu non plus d'erreur concernant le GC. Tu as bien vérifié que > > nul part ton appli (une dépendance ?) ne modifie les paramètres du > > GC ? Il s'agit bien d'un build ruby « officiel » (pas trop bricolé) de > > ton OS ? > > Il s'agit bien d'un build "officiel" de ruby. Je n'ai pas verifie > qu'aucune gem ne modifie le GC (on a 180 gems, donc bon) > Normalement, notre appli ne le modifie pas du tout mais c'est une tres > bonne question et je regarderai > > > À défaut de nous montrer le code, nous montrer au moins l'erreur :-) > > Je l'ai pas fait a la base parce que les segfault trace, c'est jamais > interessant, et vraiment, je voulais pas specialement deranger quelqu'un en > mode "aidez moi a debug", plutot "avez vous deja vu ca?". > > https://gist.github.com/strikyflo/083ca08885e617d1124a > https://gist.github.com/strikyflo/00b9f49670c3332b2e94 > https://gist.github.com/strikyflo/7f2160e078a1651081fd > > Ce sont les 3 differentes segfault que j'obtiens (1.7mb chacune) en > fonction de quand est ce que le GC est passe. > > Le modele + controller, reduits a leur minimum en tests font ca: > https://gist.github.com/strikyflo/6c531a3803eda2367d03 > > Il me reste encore a savoir si c'est la vue qui fait tout peter: ya > beaucoup (beaucoup ...) de haml, donc de nokogiri et cette derniere > pourrait etre la responsable. > J'ai fait enormement de tests, donc le fait de ne pas avoir (encore) > elimine la vue tient au volumes de tests sur les modeles et le controller. > Et aussi l'enchainement de meetings pour decider des strategies a adopter > vis a vis de ca (ya d'autres teams et des clients qui sont suspendu a cause > de cette migration). > > La decision a ete prise ce matin (heure chinoise) de rollback sur ruby > 2.0.0 puisque le probleme n'existe pas dans cette version, pour pouvoir > release quelque chose de stable (toutes les equipes sont en stand by pour > la nouvelle version de rails depuis 3 semaines, ca complique enormement les > process et les merge de stagner). Donc je vais pas travailler sur le > probleme dans la semaine qui va suivre. > Je posais la question surtout pour savoir si quelqu'un avait deja > experimente un probleme similaire et avait un bon hint a filer (ouais je > sais, c'est une segfault, donc ca n'arrive jamais en vrai). > Si je trouve la solution, je n'hesiterai pas a partager par contre, au cas > ou quelqu'un tombe dessus un jour :) > > > Le 18 mars 2015 19:05, Thibault Jouan <t...@a13.fr> a écrit : > > On 2015-03-18 17:02:07 +0800, Florian Dutey wrote: >> > Apres 1 semaine a ne pas comprendre ces exceptions, a constater le >> > caractere tres aleatoire de leurs apparitions, j'ai fait le postulat que >> > c'etait des segfault. Il m'a fallu 2 jours de plus pour les faire >> > apparaitre. >> >> Qu'as tu changé dans tes tests pour les « faire apparaitre » ? >> D'expérience avec ruby soit tout se passe bien et tu as ton exception >> écrite sur la sortie d'erreur, avec un code de statut de sortie de 1. >> Soit en cas de segfault, tu as un rapport d'erreur généré par ruby >> (sur la sortie d'erreur) différent des cas d'exception, le code de >> statut de sortie ne sera pas 1, et ton noyau va logger l'erreur. >> >> J'imagine que tu ne peux partager le code source responsable de >> l'erreur, mais as-tu possibilité de nous copier au moins l'erreur ? >> (éventuellement en « masquant » les chemins si confidentiel). Les >> backtraces C et ruby devraient aider un minimum. >> >> Quel est le code de statut de sortie que tu obtiens, et que log ton >> noyau dans ce cas ? >> >> >> > Evidemment le probleme est impossible a reproduire en environnement de >> > developement. Meme en demarrant l'appli avec les parametres de >> production >> > en local (ce qui est tres complique de plus a cause des CDN, des >> serveurs >> > de cache etc..). >> > Nous n'avons toujours pas non plus reussi a le reproduire en console, >> donc >> > nous avons un protocole assez nul pour reproduire l'erreur (spammer le >> > serveur sur une action precise). >> >> C'est bien le même ruby utilisé dans les deux cas ? Compilé de la >> même façon et sur la même plateforme ? >> >> >> > J'ai d'un cote, un modele (Page) qui a une propriete "content". Il >> s'agit >> > d'un JSON serialize, qui est plutot massif 90% du temps (legacy code). >> > >> > Au milieu un controller, qui fait trop de travail >> > Enfin, plusieurs vues parce qu'on utilise gon + jbuilder et un bon vieux >> > template haml (legacy, ya un plan pour switcher en SPA avec Rails::API >> en >> > backend) >> > >> > Regulierement (environ 5% du temps), je me mange une segfault quand >> > j'essaie d'acceder a la propriete "content" de mon objet Page. La >> variable >> > ne contient plus rien, car elle a ete garbage collected, bien qu'etant >> > toujours referencee pourtant. >> > Le caractere aleatoire etant quand est ce que GC a ete trigger. Il y a >> > plusieurs "mauvais endroits" ou il peut etre trigger et cela resulte en >> des >> > exceptions differentes (parce qu'on n'accede pas au meme clefs du hash, >> > mais le principe reste le meme). >> >> As-tu également du code C dans cette appli ? Cela pourrait être un >> appel free() ou similaire erroné côté C, qui est appliqué sur un autre >> pointeur que celui souhaité. Ou alors le GC détruit légitimement un >> objet, mais c'est la fonction qu'on a spécifié pour nettoyer l'objet >> (si free() ne convient pas) qui fait quelque chose d'incorrect. >> >> >> > Avez vous deja vu ce genre de choses? Je n'ai trouve personne qui >> pleurait >> > sur google que GC degageait des objets absolument "vivants", alors que >> j'ai >> > experimente le probleme 2x en 2 semaines. >> > Si vous avez deja vu ca, y'a-t-il une raison evidente que je loupe, >> et/ou >> > un fix solide? >> >> Pas vu non plus d'erreur concernant le GC. Tu as bien vérifié que >> nul part ton appli (une dépendance ?) ne modifie les paramètres du >> GC ? Il s'agit bien d'un build ruby « officiel » (pas trop bricolé) de >> ton OS ? >> >> Les derniers soucis de segmentation fault que j'ai vu, c'est soit >> ça : https://bugs.ruby-lang.org/issues/10685, soit dans 99% des cas >> mon propre code :P >> >> > Je suis aussi preneur de tout conseil qui pourrait m'aider a trouver >> > l'origine de l'erreur. >> >> À défaut de nous montrer le code, nous montrer au moins l'erreur :-) >> >> -- >> Thibault Jouan >> > > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse railsfrance@googlegroups.com Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance-unsubscr...@googlegroups.com --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance+unsubscr...@googlegroups.com. Pour plus d'options, visitez le site https://groups.google.com/d/optout .
