tunsanju / freetype-gl

Automatically exported from code.google.com/p/freetype-gl
Other
0 stars 0 forks source link

First-chance exception in vertex_buffer_render() and vertex_buffer_delete() on Intel HD Graphics 2000 #30

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I tested freetype-gl on Windows XP+8600 GT, Windows  7x64+9800GT and Windows 
7x32 + Intel HD Graphics 2000. The first two configurations of the problem is 
not observed. At the Intel HD Graphics 2000, I get messages "Access violation" 
in two places in a file vertex-buffer.cpp. Exceptions occur after several 
successful attempts sometimes glDrawElements, sometimes glDeleteBuffers.

void
vertex_buffer_render (vertex_buffer_t * self,
GLenum mode, const char * what) {
...
glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, self-> indices_id) ;/ * redundant code * 
/
glDrawElements (mode, icount, GL_UNSIGNED_INT, 0) ;/ * Access violation * /
...
}

void
vertex_buffer_delete (vertex_buffer_t * self) {
...
glDeleteBuffers (1, & self-> indices_id) ;/ * Access violation * /
...
}
glDeleteBuffers () calls _unlock () from mlock.c (crt), and an exception occurs.

The previous version of freetype-gl (where "vertex_buffer_t" called 
"VertexBuffer") works fine on the HD 2000. But there were memory leaks that I 
could not fix.

Original issue reported on code.google.com by bso...@gmail.com on 19 Jul 2012 at 7:39

GoogleCodeExporter commented 9 years ago
Do you now if self->indices_id refers to a valid buffer when the access 
violation occurs ?

Original comment by Nicolas.Rougier@gmail.com on 19 Jul 2012 at 9:02

GoogleCodeExporter commented 9 years ago
Yes, many times I double-checking, in self-> indices_id a valid identifier. 
Maybe a bug in the driver ig4icd32.dll, because on Nvidia error does not occur.

Original comment by bso...@gmail.com on 19 Jul 2012 at 10:33

GoogleCodeExporter commented 9 years ago
Does anybody else experience the same error ?

Original comment by Nicolas.Rougier@gmail.com on 19 Jul 2012 at 11:21

GoogleCodeExporter commented 9 years ago
hmm ... The exception occurs only with a remote debugger (VS2005), without the 
debugger the program works. However, the previous version launched from a 
remote debugger without it.
By the way, to be able to update the text in the text_buffer, I implemented a 
function text_buffer_clear() as:
void text_buffer_clear (text_buffer_t * self) 
{
 if (NULL ! = self-> buffer)
 vertex_buffer_delete (self-> buffer);/*Access violation (remote debug)*/
 self-> buffer = vertex_buffer_new ("v3f: t2f: c4f: 1g1f: 2g1f");
}

Original comment by bso...@gmail.com on 23 Jul 2012 at 7:14

GoogleCodeExporter commented 9 years ago
Can you try with latest trunk version ?

Original comment by Nicolas.Rougier@gmail.com on 29 Mar 2013 at 7:28

GoogleCodeExporter commented 9 years ago
Not sure if this is the right place, but I just ran across an issue that is 
likely related to this one. I'm on an embedded linux environment with a GLES 
driver that doesn't support the GL_OES_element_index_uint extension. This 
capability is necessary to use GL_UNSIGNED_INT in the call to glDrawElements. 
Otherwise only GL_UNSIGNED_BYTE and GL_UNSIGNED_SHORT are valid [1].

The fix was to use GL_UNSIGNED_SHORT and make the corresponding changes from 
GLuint to GLushort in vertex-buffer and text-buffer. It would be great if you 
could make this change upstream, even if available through a compile-time 
define.

If you agree with it, I can work on a patch. Thanks in advance.

[1] https://www.khronos.org/opengles/sdk/docs/man/xhtml/glDrawElements.xml

Original comment by helder.p...@gmail.com on 11 Apr 2014 at 7:10