Error : "nouveau_pushbuf.c:274: nouveau_pushbuf_flush: Assertion `0' failed."

[Elfayer]

Bonjour,

Je n'arrive pas a lancer un petit programme SFML 1.6 (oui 1.6 parce que je connais mieux et j'ai 1 semaines pour rendre quelque chose, donc pas le temps d'apprendre les nouveautés). J'ai l'erreur suivante :

nouveau_pushbuf.c:274: nouveau_pushbuf_flush: Assertion `0' failed.
Aborted (core dumped)

GDB me donne ce backtrace :

#0  0x00007ffff70af425 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff70b2b8b in __GI_abort () at abort.c:91
#2  0x00007ffff70a80ee in __assert_fail_base (fmt=<optimized out>, assertion=0x7ffff25f3aaa "0", file=0x7ffff25f3a88 "../../nouveau-1/nouveau_pushbuf.c", line=<optimized out>, function=<optimized out>)
    at assert.c:94
#3  0x00007ffff70a8192 in __GI___assert_fail (assertion=0x7ffff25f3aaa "0", file=0x7ffff25f3a88 "../../nouveau-1/nouveau_pushbuf.c", line=274, function=0x7ffff25f3ab0 "nouveau_pushbuf_flush")
    at assert.c:103
#4  0x00007ffff25f228e in nouveau_pushbuf_flush () from /usr/lib/x86_64-linux-gnu/libdrm_nouveau.so.1
#5  0x00007ffff323e957 in nv50_bufctx_emit_relocs () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#6  0x00007ffff3243042 in nv50_state_validate () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#7  0x00007ffff323be4f in nv50_clear () from /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
#8  0x00007ffff214e568 in ?? () from /usr/lib/x86_64-linux-gnu/dri/libgallium.so
#9  0x00007ffff7b7622f in sf::RenderTarget::Clear(sf::Color const&) () from /usr/lib/libsfml-graphics.so.1.6
#10 0x00000000004015d9 in Game::start (this=0x7fffffffdd40) at sources/Game.cpp:32
#11 0x00000000004011c0 in main (ac=1, av=0x7fffffffe1c8, envp=0x7fffffffe1d8) at sources/main.cpp:23

Voici la partie du programme qui plante :

_app(sf::VideoMode(SIZEX, SIZEY), "Test", sf::Style::Titlebar | sf::Style::Close)

while (_app.IsOpened())
    {
      _app.Clear();
      drawAll();
      const sf::Input &input = _app.GetInput();                                                                                                                                                                         
    }

J'ai une fenêtre SFML qui s'ouvre très lentement et qui rame, suivi d'un Aborted.
Si j'enlève la ligne "_app.Clear()", le programme tourne parfaitement. (Je veux dire par là que la fenêtre se lance rapidement et que je peux la déplacer sans problèmes)

Avez-vous une idée ? =/

Merci d'avance !

[Laurent]

Ce serait bien de voir un vrai code, pas un truc collé à la va vite avec des erreurs dedans

Et si c'est RenderWindow::Clear qui plante, ce serait bien de le tester dans un code minimal plutôt qu'à essayer de debugger ton gros projet.

[Elfayer]

J'ai essayé d'envoyer le plus d'informations possible.
Pour clarifier, voici un main qui plante :

#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>

int main()
{
  sf::RenderWindow app(sf::VideoMode(600, 600), "Test", sf::Style::Titlebar | sf::Style::Close);
  while (app.IsOpened())
    {
      app.Clear();
    }
  return (0);
}

[Laurent]

Est-ce que d'autres applications OpenGL fonctionnent ? Par exemple glxgears ?

Est-ce que tu peux tester un exemple simple avec SFML 2.1 pour voir si ça fait une différence ?

[Elfayer]

Je peux te dire que j'ai un autre projet bien plus avancé en SFML 1.6 qui tourne parfaitement, c'est pour ca que je n'y comprend rien. Je n'utilise pas de OpenGL sur mes projets actuellement. (et je ne connais pas glxgears, de nom en tout cas)

[Laurent]

Je peux te dire que j'ai un autre projet bien plus avancé en SFML 1.6 qui tourne parfaitement,

Dans ce cas reproduit le même code mais dans cet autre projet, et vois si ça plante aussi.

Je n'utilise pas de OpenGL sur mes projets actuellement.

C'était pas la question. Je parle d'OpenGL car c'est ce que SFML utilise, et c'est ce qui plante

et je ne connais pas glxgears, de nom en tout cas

C'est un programme généralement livré avec OpenGL (directement ou via un package d'outils séparés) et qui sert de référence pour vérifier le bon fonctionnement et les performances de base d'OpenGL.

[Elfayer]

Dans ce cas reproduit le même code mais dans cet autre projet, et vois si ça plante aussi.

Sa risque d'être compliqué le code est très très lourd et je ne suis pas le seul à y contribuer.

C'était pas la question. Je parle d'OpenGL car c'est ce que SFML utilise, et c'est ce qui plante

J'y ai pensé en l'écrivant, mais n'ayant pas le code source. ^^

Si tu ne peux rien me conseiller d'autre, je tenterais de revoir le code de mon autre programme qui fonctionne demain.

[Laurent]

Sa risque d'être compliqué le code est très très lourd et je ne suis pas le seul à y contribuer.

Meuh non...

int main()
{
#if 0

    ... plein de trucs compliqués du gros projet ...

#endif

  sf::RenderWindow app(sf::VideoMode(600, 600), "Test", sf::Style::Titlebar | sf::Style::Close);
  while (app.IsOpened())
    {
      app.Clear();
    }
  return (0);
}

[Elfayer]

Pas con ! 
Alors même merde. C'est à se demander si on y fait des Clear()...
Peut-être que non si on a un fond d'écran (et qu'on le réaffiche à chaque frame) sa ne se verra pas.

[Laurent]

En effet, il faudrait :

- si vous appelez Clear(), extraire un code le plus minimal possible qui marche toujours

- si vous n'appelez pas Clear(), insérer un simple appel quelque part sans toucher au reste du programme et voir si ça plante

[Elfayer]

J'ai finalement trouvé la solution !

Le problème venait du fait que je ne faisait jamais de "app.Display()".

Avec ce code ca fonctionne parfaitement :

_app.Clear();
_app.Draw();
_app.Display(); // Sans cette ligne j'ai le comportement décrit plus haut

Voilà !

La bonne question maintenant serait : Pourquoi ca fait ca ? ^^

[Laurent]

Alors là... le mystère des drivers. Faut pas chercher