Plantage assuré : jeu de test

christophe charron · Message par **christophe charron** » 25 juin 2008, 10:33

Bonjour,

ca y est, j'ai enfin pu isoler et surtout faire un jeu de test reproduisant mes soucis avec le RDF, les arbres et FF3.

Avertissement aux téméraires : j'arrive a faire crasher FF3 presque à tous coups. Pas d'autre casse, a priori, que de sortir mais bon, ne faites que cela, on ne sait jamais.

ici http://test03.christophe-charron.org/pu ... test01.php

une fenêtre xul chargeant coup sur coup 2 fichiers rdf dans un arbre.

Absolument aucun souci avec Flock, sous windows (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080530 Firefox/2.0.0.14 Flock/1.2.1), c'est à dire que l'on ne voit dans l'arbre que les données du second fichier rdf. De même, si l'on ouvr et ferme successivement les fichiers via les boutons idoines, aucun plantage.

Par contre, sous FF3, sous windows, mon arbre conserve les données du premier rdf et si l'on joue un peu avec les fichiers rdf (les ouvrir puis les fermer, puis les ouvrir, en cliquant sur l'arbre etc) on a de grandes chances d'avoir des crashes.
Sous Ubuntu 8.04, je plante, mais sans proposition d'envoi de rapport de crashes, et d'ailleurs about:crashes m'est indiqué comme une adresse invalide. Je verrai cela plus tard, si je conserve FF3...

Au hasard, les liens vers les 4 premiers crashes générés par cette fenêtre.

http://crash-stats.mozilla.com/report/i ... 1321b13766
http://crash-stats.mozilla.com/report/i ... 1cc45a2ce4
http://crash-stats.mozilla.com/report/i ... 1321b13766
http://crash-stats.mozilla.com/report/i ... 1321b13766

Dans mon appli web j'ai une foultitude d'arbres et le contenu de ces arbres évolue tout le temps en fonction des critères de recherches.

Merci à ceux qui ont d'autres versions à base de FF2 sous d'autres OS de confirmer ou infirmer.
Merci aux téméraires de me confirmer et l'affichage foireux et le plantage de FF3 sous de multiples OS.

Avez-vous des trucs pour éviter l'affichage faux et le plantage, en attendant une correction officielle ?

D'avance, merci.

Mocramis · Message par **Mocramis** » 25 juin 2008, 12:06

Effectivement, plantage à tous les coups (quand on reviens sur une des fenètres). c'en est bluffant...

Reste à envoyer ça aux développeurs de ff...

teoli2003 · Message par **teoli2003** » 25 juin 2008, 12:23

Yep, le fait crasher aussi chez moi. Il faut faire une entrée dans bugzilla.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Mocramis · Message par **Mocramis** » 25 juin 2008, 13:32

question: ça donne quoi sur ff3 sous linux ou mac ?

christophe charron · Message par **christophe charron** » 25 juin 2008, 13:34

Mocramis a écrit :question: ça donne quoi sur ff3 sous linux ou mac ?

Comme je l'ai dit dans le post initial, sous ubuntu 8.04 bingo à tous les coups aussi mais sans rapport de crash. Suis quand même preneurs sous d'autres linux et mac.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9) Gecko/2008052906 Firefox/3.0

christophe charron · Message par **christophe charron** » 25 juin 2008, 13:35

Mocramis a écrit :Effectivement, plantage à tous les coups (quand on reviens sur une des fenètres). c'en est bluffant...

Reste à envoyer ça aux développeurs de ff...

Oui, mais comment formuler ??

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080530 Firefox/2.0.0.14 Flock/1.2.1

teoli2003 · Message par **teoli2003** » 25 juin 2008, 13:40

christophe charron a écrit :
Mocramis a écrit :Effectivement, plantage à tous les coups (quand on reviens sur une des fenètres). c'en est bluffant...

Reste à envoyer ça aux développeurs de ff...
Oui, mais comment formuler ??

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080530 Firefox/2.0.0.14 Flock/1.2.1

Un truc du genre

Title: Systematic crask on http://...

When we go to http://... than come back it crashes. Here a few breakpad entries.

Steps to reproduce:
1) Open a new Firefox
2) Go to http:/...
3) < autre pas nécessaire >
4) < autre pas nécessaire >

Avec sévérité "Critical".

pirlouy · Message par **pirlouy** » 25 juin 2008, 13:47

Merci pour le "testcase".

L'idéal, pour bugzilla, serait de trouver le truc précis (la commande, le code, etc.) qui fait crasher Firefox, afin de le mentionner dans le titre... Il faudrait également, je pense, des rapports de crashs (avec Windows, puisqu'avec Ubuntu, tu ne dois pas pouvoir).

teoli2003 · Message par **teoli2003** » 25 juin 2008, 13:51

En général, si le crash est facilement reproductible (ce qui est le cas), il n'est pas nécessaire de donner un "minimal case". Ca attire vite l'attention les bugs marqués "critique" qui crachent systématiquement.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

pirlouy · Message par **pirlouy** » 25 juin 2008, 13:54

D'accord... Tu vois, j'avais peur qu'il ne se retrouve en 2 temps 3 mouvements en won't fix ou autre connerie du genre

teoli2003 · Message par **teoli2003** » 25 juin 2008, 13:59

Euh, non, non, le seul risque c'est en RESOLVED DUPLICATE of ... , mais cela signifie qu'un autre bug sur le même sujet est déjà connu.

Mais WON'T FIX sûrement pas.
Il faut par contre vérifier que cela crashe sur le Trunk aussi, mais ça je peux le faire ce soir.

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

christophe charron · Message par **christophe charron** » 25 juin 2008, 14:14

teoli2003 a écrit :Euh, non, non, le seul risque c'est en RESOLVED DUPLICATE of ... , mais cela signifie qu'un autre bug sur le même sujet est déjà connu.

Mais WON'T FIX sûrement pas.
Il faut par contre vérifier que cela crashe sur le Trunk aussi, mais ça je peux le faire ce soir.
Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Je suis très preneur de ce genre de vérification ...

Le bug est celui-ci : https://bugzilla.mozilla.org/show_bug.cgi?id=441785
est-il explicite et compréhensible ?

calimo · Message par **calimo** » 25 juin 2008, 15:30

Ce n'est pas vraiment un testcase minimal puisqu'il faut effectuer au moins une autre action pour le déclancher. Le "presque" est la chose la plus catastrophique qui peut arriver à un développeur, car ça veut dire qu'on a pas tout à fait isolé le problème *.

Le "play a little with files rdf" est un peu vague, il aurait plutôt fallu dire quelque chose de plus précis (p.ex "Click on another tab, and then click again on the tab of the test").

En gros, plus c'est précis, mieux c'est, mais je crois que c'est suffisant pour le reproduire (à tel point que maintenant j'ai un onglet ouvert que je ne peux même plus fermer

)

* mais comme tu (et nous non plus) n'est pas un développeur, c'est tout à fait suffisant amha

Edit : c'est suffisant, la preuve, il vient d'être confirmé

calimo · Message par **calimo** » 25 juin 2008, 17:04

nsXULTemplateQueryProcessorRDF::CheckIsSeparator
Il y a des <splitter> dans ton code, est-ce que par hasard ça ne pourrait pas être ça ?

Quelques suggestions pour essayer de simplifier le testcase.

Tu as 4 fonctions javascript. Sont-elles vraiment nécessaires ? Est-ce qu'on ne peut pas faire ça en exécution linéaire ? Le getElementById est dans un try/return, mais est-ce que sur cette page ça pourrait ne pas fonctionner ? Le fait que les fonctions s'appellent mutuellement en particulier embrouille pas mal les choses, d'autant qu'un seul appel est probablement suffisant. Et les commentaires ? Ils semblent ne pas apporter d'éclairage sur ce qui se passe, ce sont juste des lignes éliminées, donc autant les ôter tout à fait.

Le Math.random() n'apporte-t-il pas simplement plus de complexité, ou bien est-il indispensable au crash ? Peut-on le remplacer simplement par un chiffre ?

Le

Code : Tout sélectionner

<hbox>
    <button label="1° rdf" oncommand="fa_ouvre('civilites_bis.php');"/> <button label="2° rdf" oncommand="fa_ouvre('civilites.php');"/>
   </hbox>

est-il réellement nécessaire ? Est-ce que ça crashe sans ?
On peut aller encore plus loin, et essayer de supprimer les flex="40" (parmi d'autres).
Dans la 2è hbox, il y a plusieurs lignes. Est-ce qu'une seule ne suffirait pas ? Et les colonnes ?

Un autre point gênant est que si je fais "enregistrer sous", j'obtiens un fichier, mais si je l'ouvre il n'y a plus de plantage. Est-ce que tu n'arriverais pas à faire une page auto-suffisante ? (l'arbre chargé... sauf si le chargement est la cause du crash, mais vu que ça plante après le chargement, ça vaut probablement la peine d'essayer) J'imagine que les développeurs voudront peut-être simplifier encore le testcase, se focaliser sur un aspect, ce n'est pas évident si la page ne peut pas être enregistrée aisément...

Tout ça sont quelques exemples de pistes pour essayer de faire un test02.php qui permettrait de dire "cliquez sur la ligne" comme simple "mode d'emploi". Dans l'idéal, il devrait également être minimal, c'est-à-dire qu'on ne peut plus rien enlever sans que ça ne crashe plus, mais c'est peut-être l'étape suivante

teoli2003 · Message par **teoli2003** » 25 juin 2008, 17:12

A noter que le bug a été complété (titre, keyword, module, ...).

A moins d'un testcase plus minimal, plus qu'à attendre, mais c'est plutôt bon signe pour une correction (pas de DUPLICATE en plus semble-t-il!).

Message envoyé avec : Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Geckozone

Plantage assuré : jeu de test

Plantage assuré : jeu de test

Qui est en ligne ?