glUniform4fv Crash

[snoob741]

Moin,

ich verwende in meiner Applikation zum dynamischen Updaten der Lichtquellenfarben aktuell folgenden Aufruf:

Code: Alles auswählen

case brGraphics::brShaderParameter::eType::FLOAT_ARRAY_VEC4:
{
          std::vector<float> data(4);
          param->getValues(data, 4);

          // only update uniform if we got valid data
          unsigned int size =  data.size();
          if(size==4){
             glUniform4fv(hookID, size, &data[0]);
             //glUniform4f(hookID, data[0], data[1], data[2], data[3]);
          }
}

Das lief bisher auch ganz gut. Neuerdings erhalte ich jedoch nach einigen Minuten Laufzeit
und zig maligem Durchlauf dieses Aufrufs einen Segmentation fault. Laut GDB backtrace
genau am Aufruf von glUniform4fv.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3b49c13 in ?? () from /usr/lib/nvidia-304/libnvidia-glcore.so.304.117
(gdb) bt
#0 0x00007ffff3b49c13 in ?? () from /usr/lib/nvidia-304/libnvidia-glcore.so.304.117
#1 0x00007ffff5a28521 in binrev::brOpenGL3::brGLSLLinker::updateUniform (this=0x15a2b40, param=std::shared_ptr (count 8, weak 0) 0x12ae0d0)
at /home/hellhound/repository/binrevengine-code/renderer/brOpenGL3/trunk/src/GLSL/brGLSLLinker.cpp:471

Sehe hier aber keinen kritischen Punkt, auch beim Debuggen sind alle Werte valide, d.h.
ich habe die richtige und gültige HookID, die vec size im Shader ist auch 4 (hier liegt allerdings
auch ein Array vor) und auch die Daten sind vorhanden. Stelle ich das ganze auf den Aufruf
ohne Vektor um, läuft alles sauber durch.

Letztendlich denke ich macht es auch performance technisch keinen Unterschied ob ich die Werte als Array übergebe oder
vorher einzeln auslutsche ... Finde nach wie vor den Array Ansatz nur sauberer.

Hat jemand eine Idee was hier schief laufen könnte?

Vielen Dank schonmal!
Christian

[Jonathan]

Wenn es eine Anwendung ist, bei der ständig etwas neues passiert, wäre es möglich, dass irgendwo etwas schief läuft, was sich dann erst darin äußert, dass es an eben dieser Stelle crasht. Wenn immer und immer wieder genau der selbe Code ausgeführt wird (d.h. wenn es einmal ging, sollte es ja beim nächsten mal genauso gehen), könnte es sein, dass du irgendwo ein kleines Ressourcen Leck hast.

Ich hatte mal einen Fehler der sehr schwer zu finden war und habe ihn letztendlich mit "Dr. Memory" beheben können. Es lag letztendlich an nicht initialisiertem Speicher, der unter bestimmten Umständen (ungünstige Werte im Speicher) zu einer Endlosschleife geführt hat. Was ich damit sagen will ist, dass du vielleicht einfach mal ein paar Debugging-Tools auf deine Anwendung loslassen solltest, vielleicht findest du ja einen Fehler, der bisher lange Zeit unentdeckt blieb.

[snoob741]

Danke für Deine Tipps. Die Stelle selbst ist ja unkritisch. Dachte erst es könnte am STL Container liegen aber auch nen neu allokiertes, sauberes Array geht an der Stelle krachen. D.h. das Uniform Mapping steigt hier aus ...

Habe inzwischen die selbe Vermutung wie Du. Hab das ganze mit Valgrind getestet. Nur läuft das ganze dann dummerweise ohne Crash... Dr. Memory kenne ich noch nicht, werde ich mir mal anschauen. Kennst Du ggfs. noch nen anderes Tool? Werde bei Gelegenheit auch noch mal den glDebugger laufen lassen ...

[Sternmull]

Falls du mehrere Threads verwendest könnte die Ursache auch darin liegen das der Vektor von mehreren Threads ohne korrekte Synchronisation verwendet wird.