search

GL-MPRI-2014 / Ocawai

OCAWAI
8 stars 3 forks source link

Segfault en OCaml ?!? #41

Closed mathias-sm closed 9 years ago

mathias-sm commented 10 years ago

"make run" sans interface graphique renvoie un segfault. Argh ! Où est caché le Obj.magic ?

J'ai cherché à vérifier la présence d'environnement graphique avant une quelconque instruction de sfml, et ça s'est avéré assez compliqué ...

Pour l'instant, j'en suis au point (non satisfaisant) suivant : si je remplace le main.ml de l'interface par "Open Menus" et c'est tout, ça segfault déjà, alors que "open OcsfmlGraphics" ne pose pas problème. Mais je n'ai pas le temps maintenant de trouver ce qui pose problème dans Menu.ml !

A suivre !

VLanvin commented 10 years ago

Alors ça c'est curieux, d'autant plus que je n'arrive pas à le reproduire.

La seule évaluation que Menu.ml fait à l'ouverture est le chargement d'une font, sinon il ne contient que des classes...

tbazin commented 10 years ago

Trop la classe !

Théis

De : Artymortmailto:notifications@github.com Envoyé : ‎25/‎10/‎2014 22:51 À : GL-MPRI-2014/GL_MPRI_2014mailto:GL_MPRI_2014@noreply.github.com Objet : [GL_MPRI_2014] Segfault en OCaml ?!? (#41)

"make run" sans interface graphique renvoie un segfault. Argh ! Où est caché le Obj.magic ?

J'ai cherché à vérifier la présence d'environnement graphique avant une quelconque instruction de sfml, et ça s'est avéré assez compliqué ...

Pour l'instant, j'en suis au point (non satisfaisant) suivant : si je remplace le main.ml de l'interface par "Open Menus" et c'est tout, ça segfault déjà, alors que "open OcsfmlGraphics" ne pose pas problème. Mais je n'ai pas le temps maintenant de trouver ce qui pose problème dans Menu.ml !

A suivre !

Reply to this email directly or view it on GitHub: https://github.com/GL-MPRI-2014/GL_MPRI_2014/issues/41

mathias-sm commented 10 years ago

Bon, j'avance de la traque de sous ensemble minimal permettant de reproduire le bug.

Ce n'est donc pas dans les open des fichiers en question, mais bien dans les fichiers eux même ?

Est-ce que quelqu'un arrive à reproduire le bug ? (Pour ma part sous linux je fais ctrl+alt+fX pour avoir un TTY et je fais un make run dedans, ça suffit.)

VLanvin commented 10 years ago

C'est bon je l'ai, et c'est tout à fait normal (du moins, pas de notre faute).

Ca vient directement de la SFML, dans la fonction chargée d'ouvrir le contexte openGL (merci gdb). Forcément, la fonction ne pouvant pas accéder à l'affichage envoie une jolie segfault.

mathias-sm commented 10 years ago

Ah, gdb c'était me prochaine étape !

Du coup il faudrait pouvoir faire un test avant l'appel en question pour s'éviter un segfault, parce que même s'il faut être un peu niais pour lancer l'interface sans environnement graphique, la ça fait pas sérieux du tout...

VLanvin commented 10 years ago

J'ai un peu cherché, mais je n'ai aucune idée de comment on peut s'y prendre pour réaliser un test pareil. Que ce soit en Ocaml ou en C++. Je n'ai pas trouvé de fonction de test dans la SFML, ni dans toutes les fonctions système (pourtant il doit bien y en avoir une). Sinon il me semble (vague souvenir, probabilité < 0.1) qu'il y en a une en openGL qui pourrait convenir, mais rajouter un binding openGL pour si peu, c'est lourd. Et à côté, l'installation d'Ocsfml c'est du gâteau.

dbaelde commented 10 years ago

Peut-on avoir des détails sur le nom de la fonction? Cela ne serait pas très propre que SFML ne permette pas d'éviter une segfault pour ce cas.

VLanvin commented 10 years ago

La fonction qui sefault est sf::priv::GlxContext::GlxContext(sf::priv::GlxContext). Elle appelle Display openDisplay() et ne vérifie pas que le Display* renvoyé est <> NULL avant de l'utiliser.