crashes on score loading

[avilleret]

j'étais tout content quand j'avais enfin réussi à enregistrer tout mon namespace OSC sans faire crasher i-score que je me suis dépêché de sauvegarder mon score. sauf qu'au chargement, patatra, ça plante... voilà le crashlog et le score incriminé : https://gist.github.com/avilleret/bfacf8df4ab7d022fcdc c'était sous 10.7.5 avec i-score 2.2b2

[avilleret]

oups, j'ai aussi un crash sous Ubuntu avec une version fraîchement compilée, j'ai ajouté le backtrace au Gist cité dans mon premier post i-score a été compilé depuis la branche release/0.2 et Jamoma depuis la branche dev (par défaut avec le script ./build.sh de OSSIA)

[avilleret]

:-(

[jcelerier]

Ca a l'air d'être dans le moteur vue la trace :

0 0x00007ffff7ada1f4 in bool std::__lexicographical_compare_impl<TTElement

const, TTElement const, gnu_cxx::__ops::_Iter_lessiter>(TTElement const, TTElement const, TTElement const, TTElement const_, gnu_cxx::__ops::_Iter_less_iter) [clone .isra.93]()

from /usr/local/lib/jamoma/lib/libJamomaFoundation.so

1 0x00007ffff7adeec6 in

compareNodePriorityThenNameThenInstance(TTValue&, TTValue&) () from /usr/local/lib/jamoma/lib/libJamomaFoundation.so

2 0x00007ffff7ab6541 in void std::list<TTValue,

std::allocator >::sort<bool (*)(TTValue&, TTValue&)>(bool (_)(TTValue&, TTValue&)) () from /usr/local/lib/jamoma/lib/libJamomaFoundation.so

3 0x00007ffff7ab5d12 in TTList::sort(bool (_)(TTValue&, TTValue&))

() from /usr/local/lib/jamoma/lib/libJamomaFoundation.so

4 0x0000000000468859 in Engine::requestObjectChildren(std::string

const&, std::vector<std::string, std::allocator >&) ()

JM

---

Jean-Michaël Celerier http://www.jcelerier.name

On Sat, Nov 8, 2014 at 12:33 PM, Antoine Villeret notifications@github.com wrote:

:-(

— Reply to this email directly or view it on GitHub https://github.com/i-score/i-score/issues/54#issuecomment-62254714.

[bltzr]

tu nous enverrais ton fichier .score ?

[avilleret]

bah il est dans le Gist : https://gist.github.com/avilleret/bfacf8df4ab7d022fcdc/download#

[bltzr]

ooops, pardon !

bon, chez moi il ne plante pas, mais il ne charge pas la device non plus… je teste...=

[bltzr]

OK, il s’embrouillait entre l’UTF-16 et 8 (bizarre)… en changeant 16 en 8 au début,il arrive à charger… enfin, à crasher :-)

[bltzr]

OK, j’ai trouvé… for some reason, c’est ton noeud vague à la ligne 64 qui fait planter… pourquoi, je ne le sais pas encore…. mais je cherche..=

[bltzr]

plus précisément, c’est le sous-noeud "face-lointain” du noeud “vague” qui fait planter… j’ai essaye de le renommer ou d’enlever des sous-noeuds, et ça ne règle pas le problème… bizarre, bizarre... =

[bltzr]

et, encore plus précisément, c’est la coexistence de “face-lointain” avec les noeuds numériques qui fait planter Jamoma en fait, je pense que ça vient d’un changement récent fait par Théo, qui permet de considérer différemment les noeuds numériques et symboliques, notamment pour éviter les aberrations de classement, du genre (1 10 11 2 3 etc…)

du coup, dans l’immédiat, d’ici à ce que Théo règle ça, interdiction de mélanger noeuds numériques et symboliques sur un même niveau… je réfléchis à un workaround...=

[bltzr]

bon, désolé, pas de workaround, en fait… mais j’imagine que Théo va régler ça lundi ou par là...=

[theod]

marrant ! c'est un bug que j'ai résolu pour Julien dans Max vendredi :-) je mets à jour Jamoma dans Score de ce pas

[jln-]

Toi, tu as le sens de l'humour ! ;-)

[theod]

c'est pouché ! je vous laisse vérifier

[bltzr]

donc c'est réglé ? on peut fermer l'issue ?

[avilleret]

oui c'est bon, le chargement du score ne crash plus