4. Crash in fglrx_dri.so - was jetzt

Crash in fglrx_dri.so - was jetzt

  • D

    Mein Programm wird mit Signal 11 in glLoadIdentity() beendet. Der Trace zeigt fogendes:

    #0 0xb61ccaff	??() (/usr/lib/dri/fglrx_dri.so:??)
#1 0x1	??() (??:??)
#2 0xac5752c4	??() (??:??)
#3 0xac5752d8	??() (??:??)
#4 0xb7b32ff4	??() (/lib/i686/cmov/libpthread.so.0:??)
#5 (	??() (??:??)

    ein »Minimalbeispiel« mit dem selben Code (Copy&Paste) läuft ohne Probleme, der Code lief unverändert (der ogl/x11 Teil unverändert) mit einem älteren fglrx fehlerfrei.

    Der Trace sagt mir verständlicherweise sehr wenig ... wie komme ich an die benötigten Informationen um das Problem zu beheben? Im Debugger kann ich den Crash auf den aufruf von glLoadIdentity(); zurückverfolge.

    Kann ein fehlerhafter Speicherzugriff in meinem Code den stack einer *.so überhaupt beeinflussen?

    0
  • B

    hi,
    du könntest erstmal für die entsprechenden libraries die debug-versionen installieren und dein programm mit debug-informationen kompilieren lassen. damit verschwinden erstmal die ganzen "???"

    mfg blan

    0
  • D

    Ich hab nur leider keinerlei zugriff auf AMDs Treiber - und somit auch keine debug-librarys für fglrx.

    Mit valgrind bekomme ich tatsächlich die Symbole, allerdings sagt mir das auch nicht mehr, als das, was ich bereits weiß.

    EDIT://

    0xb5aa0dd0 - 0xb66f4b10 is .text in /usr/lib/dri/fglrx_dri.so
    0
  • D

    Sieht so aus als nimmt der neue Treiber es einem übel, wenn man X in einem anderen Thread initialisiert hat als dann für das ogl Rendering verwendet wird.

    Weiß jemand ob das ...

    a) ... das ganze nur zufällig behebt und ich einen Fehler anderswo haben muss
    b) ... das ein Fehler im Treiber ist
    c) ... OpenGL + DRI ein solches Vorgehen einfach nicht erlaubt

    Ich kann garantieren, dass es zu keinen Races kommt, da der Thread erst gestartet wurde, als die initialisierung abgeschlossen war und sonst keine zugriffe auf X / OGL erfolgen.

    0
  • B

    kann es nicht sein, dass nicht alle libraries die du verwendest thread-safe sind?

    mfg blan

    0
  • D

    Weder X noch OGL sind von sich aus Threadsafe 😉 X bietet nach XInitThreads() allerdings einen eigenen Locking-Support.

    Von OpenAL kann ich's nicht sage, sollte aber hier keine Rolle Spielen, RakNet verwendet selbst Threads und hat nur die Einschränkung, dass man den zugriff Locken muss.

    An sich kann es kaum zu races kommen, höchstens wenn ich irgendeinen X / OGL Buffer nicht rechtzeitig geflusht habe

    0
Anmelden zum Antworten