I’m trying to trace down a/bugs that causes my graphics-card to pop a time out and close down the program.
What could possibly cause this function to not reach the end and pop an error-message?
I traced the bug down to a call that are spawned in the ‘cursor-move()’ on a vector with 3 dvec2 and using the very first base_vertex (=0) in the vertex-buffer. So, it’s one of the most executed functions and only contents of the vector changes.
The bug appears as a response to my interactions on the screen with the mouse … that is: an elaborate part of code (with buffer-writes) is executed right before the execution returns to the cursor-move() function.
There are numerous places where code can fail, it’s just not there the execution halts. I use a hastely implimented garbage-collector of own design. It fails spectacularly when used in the text-program, but never seems to cause opengl to throw errors. I suspect that there can be some unexpected error in reusing space in the vertex-buffer.
While you look at this, I will go through the code to see if the vector used are tampered with on a mistake.
When turning on debugging the error does not reproduce.
void make_tmp_update(GLint base_vertex,const vector<glm::dvec2>& to_value, bool doDebug){
if(base_vertex<0){
cout << "make_tmp_update.base_vertex ERROR\n";
return;
}
if(doDebug){
cout << "tmp_upd.bv: " << base_vertex << " ";
for(GLuint i=0;i<to_value.size();i++){
cout << i << " x,y: " << to_value.at(i).x << ", " << to_value.at(i).y << "\n";
}
}
GLfloat* mpPositions=(GLfloat*)NULL;
GLsizeiptr byte_length = (GLsizeiptr) 4*4*to_value.size() ;
glUseProgram( mBuffer.Program );
glBindVertexArray(mBuffer.VAO);
glBindBuffer(GL_ARRAY_BUFFER, mBuffer.VBO);
glEnableVertexAttribArray(0);
//chars byte-offset
mpPositions = (GLfloat*) glMapBufferRange(GL_ARRAY_BUFFER, (GLintptr) 4*4*base_vertex , (GLsizeiptr)byte_length , GL_MAP_WRITE_BIT) ;
if( mpPositions!=(GLfloat*)NULL ){
for(GLuint i=0;i<to_value.size();i++){
mpPositions[ 4*i + 0 ] = (GLfloat)to_value.at(i).x ;//vec2 or dvec2 ?
mpPositions[ 4*i + 1 ] = (GLfloat)to_value.at(i).y ;
}
glFlush();
//glFinish();
glUnmapBuffer(GL_ARRAY_BUFFER);
glDisableVertexAttribArray(0);
glUseProgram( 0 );
}
else{
cout << char(7) << "gui_program.make_tmp_update() ERROR" << endl;
}
bool tstr=test_for_error("make_tmp_update a");
if(tstr){
cout << "base_vertex: " << base_vertex << "\n" ;
}
return;
}
the error moved to the end of the general draw-function. It contains a lot of separate minor specific opengl draw-calls. The exit is covered by testing opengl-error and none is detected.
// edit
eventually it repeated in make_tmp_update in debug-mode showing sane input.
// edit edit
I wrap all stuff related to a pair of shaders and their program into a class.
This class has a data-member, a struct mBuffer that holds the buffer identifiers and a few other ints. It’s not fixed by new. The program-wrapper is rather long … maybe it looses track of it’s members. That’s atleast something I’ve kinda seen before. I’ve never deleted the shader-strings of the wrapper though they are only used once.
I’ll redo and see if it helps.
//edit edit edit
Made the changes and it didn’t resolve anything
Let me make sure I understand you correctly: your program gets killed by the OS because it executes a GPU command that takes to long to complete, i.e this in case of Windows? In that case I would be looking at your shader code for cases of loops that could have unbounded iteration counts - including cases where this could happen because some buffers/textures/uniforms have invalid contents.
Hi Carsten,
I’m not sure the diagnostics on the link matches, but I’ve saved it for further scrutiny. I have 3 fatal error-types. gdb detected segment faults, frosen screen that will need opening ‘running processes’ to stop and the one I talk about: the windowing host pops a time-out and the exit is fairly civil.
I have my code littered with debug-code. Every opengl swapbuffers has atleast one glGetError(). There are cout<< for code that does not execute too often and a logger that writes to file multible times for every increment of cursor-move and within draw-code. This debugging are beginning to fail too … maybe because the file-logging generates 50000 lines within a few minutes. I only need the last couple of lines, and so far, it’s given me precious little. Or should I say: nothing that makes sense. I’m taking a break. The last change I made needed 400 minor identical changes (search and replace), so I’ve better think twice before I do something.
I’ll have a look at the uniforms in a parallel (text) program-object,
Thanks for your input.
//edit: There’s a line of error-prevention I’ve tried to follow, but somewhat failed: How does one test a std::list<…>::iterator to see if it’s obsolete? If it’s no good I risk to shut-down the execution.
You can’t. You just have to ensure that you don’t retain iterators across calls which can delete elements (unless you know that they won’t delete the element the iterator refers to).
Yes, that part of the program feels like dancing in a mine-field.
I’m beginning to suspect, that the reason for my inabillity to solve my problems is, that stepping on one of the mines may make errors elsewhere (in the graphics driver?). When they kick in and I ‘think’ that it’s my latest code-changes that errs, I’m sort of handicapped in doing things right.