digitalmars.D.learn - [Windows & DMD] No callstack when crash with Access violation reading
- Xavier Bigand (5/5) Jan 11 2014 I get some troubles to solve a memory bug, just cause I don't have any
- Namespace (2/8) Jan 11 2014 Try to compile with -gc
- Xavier Bigand (2/11) Jan 11 2014 Doesn't change anything.
- Benjamin Thaut (6/11) Jan 11 2014 For x64 exeuctables compile with -g.
- Xavier Bigand (3/16) Jan 11 2014 Yep I am using VisualD with cv2pdb, and I build in debug mode with the
- Benjamin Thaut (7/25) Jan 11 2014 And it does not print a stack trace? Is it possbile that this access
- Xavier Bigand (3/30) Jan 11 2014 Yes I have no stack trace and adding import core.sys.windows.stacktrace
- Benjamin Thaut (5/7) Jan 11 2014 That is very strange. Can you reduce this? Or is this project on github
- Xavier Bigand (21/29) Jan 11 2014 Yes it's on github :
- Benjamin Thaut (6/39) Jan 11 2014 If you use VisualD why don't you go to "Debugging->Execptions" in Visual...
- Xavier Bigand (3/48) Jan 11 2014 I didn't know this menu settings, but activate Access Violation don't
- Benjamin Thaut (20/22) Jan 12 2014 It seems that your crash happens inside the OpenGL part of the graphics
- Xavier Bigand (4/27) Jan 12 2014 Thank for your support and your time
- Benjamin Thaut (12/44) Jan 12 2014 I higly recommend using either glIntercept
- Xavier Bigand (5/51) Jan 13 2014 I took a look to buffers manually just before the glDrawElements call,
- Xavier Bigand (40/95) Jan 13 2014 I finally tried glIntercept, but I am not sure how I need interpret the
- Benjamin Thaut (18/47) Jan 13 2014 Yes this indeed looks correct.
- Xavier Bigand (8/61) Jan 18 2014 I am not sure the issue come really from my code, cause it just works
- TheFlyingFiddle (20/27) Jan 21 2014 From what i saw in your code you are not using Vertex Array
- Flamaros (4/36) Jan 22 2014 I will try the global VAO.
- Xavier Bigand (5/43) Jan 29 2014 I finally found the issue, glDisableVertexAttribArray calls were
- Benjamin Thaut (12/12) Jan 11 2014 Ok, I can reproduce this, and it seems that the crash happens somewhere
- Namespace (3/9) Jan 11 2014 In a perfect world D would have a built-in solution to avoid null
- Xavier Bigand (6/11) Jan 11 2014 I am using VisualD with cv2pdb.
I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?
Jan 11 2014
On Saturday, 11 January 2014 at 16:24:08 UTC, Xavier Bigand wrote:I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?Try to compile with -gc
Jan 11 2014
Xavier Bigand <flamaros.xavier gmail.com> Le 11/01/2014 18:20, Namespace a écrit :On Saturday, 11 January 2014 at 16:24:08 UTC, Xavier Bigand wrote:Doesn't change anything.I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?Try to compile with -gc
Jan 11 2014
Am 11.01.2014 17:24, schrieb Xavier Bigand:I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?For x64 exeuctables compile with -g. For x86 executables compile with -g and then run cv2pdb on the final executable. cv2pdb is part of VisualD. Kind Regards Benjamin Thaut
Jan 11 2014
Le 11/01/2014 18:45, Benjamin Thaut a écrit :Am 11.01.2014 17:24, schrieb Xavier Bigand:Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g.I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?For x64 exeuctables compile with -g. For x86 executables compile with -g and then run cv2pdb on the final executable. cv2pdb is part of VisualD. Kind Regards Benjamin Thaut
Jan 11 2014
Am 11.01.2014 19:16, schrieb Xavier Bigand:Le 11/01/2014 18:45, Benjamin Thaut a écrit :And it does not print a stack trace? Is it possbile that this access violation happens within a module constructor? Try importing core.sys.windows.stacktrace into every single one of your modules and see if that changes something. Kind Regards Benjamin ThautAm 11.01.2014 17:24, schrieb Xavier Bigand:Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g.I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?For x64 exeuctables compile with -g. For x86 executables compile with -g and then run cv2pdb on the final executable. cv2pdb is part of VisualD. Kind Regards Benjamin Thaut
Jan 11 2014
Le 11/01/2014 19:40, Benjamin Thaut a écrit :Am 11.01.2014 19:16, schrieb Xavier Bigand:Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing.Le 11/01/2014 18:45, Benjamin Thaut a écrit :And it does not print a stack trace? Is it possbile that this access violation happens within a module constructor? Try importing core.sys.windows.stacktrace into every single one of your modules and see if that changes something. Kind Regards Benjamin ThautAm 11.01.2014 17:24, schrieb Xavier Bigand:Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g.I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?For x64 exeuctables compile with -g. For x86 executables compile with -g and then run cv2pdb on the final executable. cv2pdb is part of VisualD. Kind Regards Benjamin Thaut
Jan 11 2014
Am 11.01.2014 20:50, schrieb Xavier Bigand:Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing.That is very strange. Can you reduce this? Or is this project on github somewhere? Did you try using a debugger? Kind Regards Benjamin Thaut
Jan 11 2014
Le 11/01/2014 22:15, Benjamin Thaut a écrit :Am 11.01.2014 20:50, schrieb Xavier Bigand:Yes it's on github : https://github.com/Flamaros/DQuick/tree/Missing_RAII_Warning Ro reproduce the crash : - You can launch the DQuick-VisualD.sln solution file that is in the root folder. - Launch the Text project (in debug mode) - Resize the Window, it crash directly It seems to be related to the GraphicItem class in startPaint methode, particulary this section of code : debug { if (mRebuildDebugMeshes) updateDebugMesh(); mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Putting it under comment remove the crash. Thank you for your help.Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing.That is very strange. Can you reduce this? Or is this project on github somewhere? Did you try using a debugger? Kind Regards Benjamin Thaut
Jan 11 2014
Am 11.01.2014 22:56, schrieb Xavier Bigand:Le 11/01/2014 22:15, Benjamin Thaut a écrit :If you use VisualD why don't you go to "Debugging->Execptions" in Visual Studio and activate the "Access Violation" under "Win32 Exceptions" to debug that access violation with the visual studio debugger? Kind Regards Benjamin ThautAm 11.01.2014 20:50, schrieb Xavier Bigand:Yes it's on github : https://github.com/Flamaros/DQuick/tree/Missing_RAII_Warning Ro reproduce the crash : - You can launch the DQuick-VisualD.sln solution file that is in the root folder. - Launch the Text project (in debug mode) - Resize the Window, it crash directly It seems to be related to the GraphicItem class in startPaint methode, particulary this section of code : debug { if (mRebuildDebugMeshes) updateDebugMesh(); mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Putting it under comment remove the crash. Thank you for your help.Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing.That is very strange. Can you reduce this? Or is this project on github somewhere? Did you try using a debugger? Kind Regards Benjamin Thaut
Jan 11 2014
Le 12/01/2014 00:30, Benjamin Thaut a écrit :Am 11.01.2014 22:56, schrieb Xavier Bigand:I didn't know this menu settings, but activate Access Violation don't change anything.Le 11/01/2014 22:15, Benjamin Thaut a écrit :If you use VisualD why don't you go to "Debugging->Execptions" in Visual Studio and activate the "Access Violation" under "Win32 Exceptions" to debug that access violation with the visual studio debugger? Kind Regards Benjamin ThautAm 11.01.2014 20:50, schrieb Xavier Bigand:Yes it's on github : https://github.com/Flamaros/DQuick/tree/Missing_RAII_Warning Ro reproduce the crash : - You can launch the DQuick-VisualD.sln solution file that is in the root folder. - Launch the Text project (in debug mode) - Resize the Window, it crash directly It seems to be related to the GraphicItem class in startPaint methode, particulary this section of code : debug { if (mRebuildDebugMeshes) updateDebugMesh(); mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Putting it under comment remove the crash. Thank you for your help.Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing.That is very strange. Can you reduce this? Or is this project on github somewhere? Did you try using a debugger? Kind Regards Benjamin Thaut
Jan 11 2014
Am 12.01.2014 00:47, schrieb Xavier Bigand:I didn't know this menu settings, but activate Access Violation don't change anything.It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut
Jan 12 2014
Le 12/01/2014 11:16, Benjamin Thaut a écrit :Am 12.01.2014 00:47, schrieb Xavier Bigand:Thank for your support and your time I already tried to debug opengl with gdebugger is used to find those kind of issues. But it doesn't seems working fine with D binaries.I didn't know this menu settings, but activate Access Violation don't change anything.It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut
Jan 12 2014
Am 12.01.2014 17:18, schrieb Xavier Bigand:Le 12/01/2014 11:16, Benjamin Thaut a écrit :I higly recommend using either glIntercept (http://code.google.com/p/glintercept/) or glslDevil (http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL applications. If you have a nvidia card you could also use nvidia nsight to debug your application: https://developer.nvidia.com/nvidia-nsight-visual-studio-edition My guess would be that either your vertex buffer or index buffer is no longer valid, thus gets not bound, and as a result the graphics driver reads from client memory at address null. Kind Regards Benjamin ThautAm 12.01.2014 00:47, schrieb Xavier Bigand:Thank for your support and your time I already tried to debug opengl with gdebugger is used to find those kind of issues. But it doesn't seems working fine with D binaries.I didn't know this menu settings, but activate Access Violation don't change anything.It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut
Jan 12 2014
Le 12/01/2014 18:01, Benjamin Thaut a écrit :Am 12.01.2014 17:18, schrieb Xavier Bigand:I took a look to buffers manually just before the glDrawElements call, and all values seems good. I also check if any glDeleteBuffers and glDeleteShader,... was called before the glDrawElements. I need find some more time to test with glIntercept or nvidia nsightLe 12/01/2014 11:16, Benjamin Thaut a écrit :I higly recommend using either glIntercept (http://code.google.com/p/glintercept/) or glslDevil (http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL applications. If you have a nvidia card you could also use nvidia nsight to debug your application: https://developer.nvidia.com/nvidia-nsight-visual-studio-edition My guess would be that either your vertex buffer or index buffer is no longer valid, thus gets not bound, and as a result the graphics driver reads from client memory at address null. Kind Regards Benjamin ThautAm 12.01.2014 00:47, schrieb Xavier Bigand:Thank for your support and your time I already tried to debug opengl with gdebugger is used to find those kind of issues. But it doesn't seems working fine with D binaries.I didn't know this menu settings, but activate Access Violation don't change anything.It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut
Jan 13 2014
Le 13/01/2014 20:42, Xavier Bigand a écrit :Le 12/01/2014 18:01, Benjamin Thaut a écrit :I finally tried glIntercept, but I am not sure how I need interpret the output : glViewport(0,0,801,600) glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) glBindBuffer(GL_ARRAY_BUFFER,10) glBufferData(GL_ARRAY_BUFFER,48,0604C000,GL_DYNAMIC_DRAW) glBindBuffer(GL_ARRAY_BUFFER,0) glBindBuffer(GL_ARRAY_BUFFER,11) glBufferData(GL_ARRAY_BUFFER,64,0604E600,GL_DYNAMIC_DRAW) glBindBuffer(GL_ARRAY_BUFFER,0) glBindBuffer(GL_ARRAY_BUFFER,13) glBufferData(GL_ARRAY_BUFFER,48,0604FFC0,GL_DYNAMIC_DRAW) glBindBuffer(GL_ARRAY_BUFFER,0) glBindBuffer(GL_ARRAY_BUFFER,14) glBufferData(GL_ARRAY_BUFFER,64,0604E580,GL_DYNAMIC_DRAW) glBindBuffer(GL_ARRAY_BUFFER,0) glUseProgram(4) glUniformMatrix4fv(0,1,false,[0.002497,0.000000,0.000000,0.000000,0.000000,-0.003333,0.000000,0.000000,0.000000,0.000000,-0.010000,0.000000,-1.000000,1.000000,0.000000,1.000000]) glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) glBindBuffer(GL_ARRAY_BUFFER,10) glEnableVertexAttribArray(0) glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000000) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000000) GLSL=4 ----->glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) ----->----->glUseProgram(4) ----->----->glUniformMatrix4fv(0,1,false,[0.002497,0.000000,0.000000,0.000000,0.000000,-0.003333,0.000000,0.000000,0.000000,0.000000,-0.010000,0.000000,-1.000000,1.000000,0.000000,1.000000]) ----->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) ----->----->glBindBuffer(GL_ARRAY_BUFFER,10) ----->----->glEnableVertexAttribArray(0) ----->----->glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) ----->----->glBindBuffer(GL_ARRAY_BUFFER,11) ----->----->glEnableVertexAttribArray(1) ----->----->glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000000) ----->----->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000000) GLSL=4 This extract seems to correspond of latest gl command called just before the crash after the window resize. It doesn't seems to have any error here.Am 12.01.2014 17:18, schrieb Xavier Bigand:I took a look to buffers manually just before the glDrawElements call, and all values seems good. I also check if any glDeleteBuffers and glDeleteShader,... was called before the glDrawElements. I need find some more time to test with glIntercept or nvidia nsightLe 12/01/2014 11:16, Benjamin Thaut a écrit :I higly recommend using either glIntercept (http://code.google.com/p/glintercept/) or glslDevil (http://www.vis.uni-stuttgart.de/glsldevil/) to debug OpenGL applications. If you have a nvidia card you could also use nvidia nsight to debug your application: https://developer.nvidia.com/nvidia-nsight-visual-studio-edition My guess would be that either your vertex buffer or index buffer is no longer valid, thus gets not bound, and as a result the graphics driver reads from client memory at address null. Kind Regards Benjamin ThautAm 12.01.2014 00:47, schrieb Xavier Bigand:Thank for your support and your time I already tried to debug opengl with gdebugger is used to find those kind of issues. But it doesn't seems working fine with D binaries.I didn't know this menu settings, but activate Access Violation don't change anything.It seems that your crash happens inside the OpenGL part of the graphics driver. It is caused by DQuick\src\dquick\renderer3D\openGL\mesh.d line 125 I assume that you setup a few OpenGL parameters invalid and thus the driver reads from a null pointer. I found it by single stepping. I started the application, then set the breakpoint like shown below and single steppt into the draw() method. debug { if (mRebuildDebugMeshes) updateDebugMesh(); // put breakpoint here mDebugMesh.draw(); if ((implicitWidth != float.nan && implicitHeight != float.nan) && (implicitWidth != mSize.x && implicitHeight != mSize.y)) mDebugImplicitMesh.draw(); } Have fun debugging ;-) Kind Regards Benjamin Thaut
Jan 13 2014
Am 13.01.2014 21:52, schrieb Xavier Bigand:glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) glBindBuffer(GL_ARRAY_BUFFER,10) glEnableVertexAttribArray(0) glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000000) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000000) GLSL=4 ----->glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) ----->----->glUseProgram(4) ----->----->glUniformMatrix4fv(0,1,false,[0.002497,0.000000,0.000000,0.000000,0.000000,-0.003333,0.000000,0.000000,0.000000,0.000000,-0.010000,0.000000,-1.000000,1.000000,0.000000,1.000000]) ----->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) ----->----->glBindBuffer(GL_ARRAY_BUFFER,10) ----->----->glEnableVertexAttribArray(0) ----->----->glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) ----->----->glBindBuffer(GL_ARRAY_BUFFER,11) ----->----->glEnableVertexAttribArray(1) ----->----->glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000000) ----->----->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000000) GLSL=4 This extract seems to correspond of latest gl command called just before the crash after the window resize. It doesn't seems to have any error here.Yes this indeed looks correct. Maybe its even a bug in the driver. Because it happens right after the window resize graphic resource might got invalid and the driver would need to re-create them. The problem ist most likely that you use two array buffers, one for each attribute, instead of using one array buffer and interleaving the attribute (this is the usual way). I could bet, that if you switch over to the interleaved variant, the problem goes away. You could also try to make the three buffers slightly larger and specifiy different pointers to see which one actually causes the invalid read. So that the calls become:----->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) ----->----->glBindBuffer(GL_ARRAY_BUFFER,10) ----->----->glEnableVertexAttribArray(0) ----->----->glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) ----->----->glBindBuffer(GL_ARRAY_BUFFER,11) ----->----->glEnableVertexAttribArray(1) ----->----->glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000016) ----->----->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000004)GLSL=4 You could then see from the access violation which of the three buffers the read attempt fails. You could also try to move the glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) right before the glDrawElements call. Kind Regards Benjamin Thaut
Jan 13 2014
Le 13/01/2014 22:47, Benjamin Thaut a écrit :Am 13.01.2014 21:52, schrieb Xavier Bigand:I am not sure the issue come really from my code, cause it just works fine on ATI cards, I do something Nvidia drivers dislike. I tried to replace GL_LINE_LOOP by triangles, increase buffer size, put the GL_ELEMENT_ARRAY_BUFFER buffer type bind right before glDrawElements without success. Crash only append when I fill text mesh before those ones. So I need dig more.glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) glBindBuffer(GL_ARRAY_BUFFER,10) glEnableVertexAttribArray(0) glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000000) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000000) GLSL=4 ----->glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) ----->----->glUseProgram(4) ----->----->glUniformMatrix4fv(0,1,false,[0.002497,0.000000,0.000000,0.000000,0.000000,-0.003333,0.000000,0.000000,0.000000,0.000000,-0.010000,0.000000,-1.000000,1.000000,0.000000,1.000000]) ----->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) ----->----->glBindBuffer(GL_ARRAY_BUFFER,10) ----->----->glEnableVertexAttribArray(0) ----->----->glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) ----->----->glBindBuffer(GL_ARRAY_BUFFER,11) ----->----->glEnableVertexAttribArray(1) ----->----->glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000000) ----->----->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000000) GLSL=4 This extract seems to correspond of latest gl command called just before the crash after the window resize. It doesn't seems to have any error here.Yes this indeed looks correct. Maybe its even a bug in the driver. Because it happens right after the window resize graphic resource might got invalid and the driver would need to re-create them. The problem ist most likely that you use two array buffers, one for each attribute, instead of using one array buffer and interleaving the attribute (this is the usual way). I could bet, that if you switch over to the interleaved variant, the problem goes away. You could also try to make the three buffers slightly larger and specifiy different pointers to see which one actually causes the invalid read. So that the calls become: > ----->glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) > ----->----->glBindBuffer(GL_ARRAY_BUFFER,10) > ----->----->glEnableVertexAttribArray(0) > ----->----->glVertexAttribPointer(0,3,GL_FLOAT,false,12,00000000) > ----->----->glBindBuffer(GL_ARRAY_BUFFER,11) > ----->----->glEnableVertexAttribArray(1) > ----->----->glVertexAttribPointer(1,4,GL_FLOAT,false,16,00000016) > ----->----->glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,00000004) GLSL=4 You could then see from the access violation which of the three buffers the read attempt fails. You could also try to move the glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) right before the glDrawElements call. Kind Regards Benjamin Thaut
Jan 18 2014
On Saturday, 18 January 2014 at 19:40:38 UTC, Xavier Bigand wrote:I am not sure the issue come really from my code, cause it just works fine on ATI cards, I do something Nvidia drivers dislike. I tried to replace GL_LINE_LOOP by triangles, increase buffer size, put the GL_ELEMENT_ARRAY_BUFFER buffer type bind right before glDrawElements without success. Crash only append when I fill text mesh before those ones. So I need dig more.From what i saw in your code you are not using Vertex Array Objects. I have had similar problems that code ran fine on ATI but crashed on nvidia. The problem went away for me when i just created and bound a global VAO just after context creation. Also i would recommend calling glGetError after every call, it helps finding errors. Here is a simple trick to do this automatically. static gl { static ref auto opDispatch(string name, Args...)(Args args) { enum glName = "gl" ~ name[0].toUpper.to!string ~ name[1 .. $]; debug scope(exit) checkGLError(); //Do glGetError and log it or something. mixin("return " ~ glName ~ "(args);"); } } After this simply change all glFunctionName(args) to gl.functionName or gl.functionName.
Jan 21 2014
On Wednesday, 22 January 2014 at 02:11:02 UTC, TheFlyingFiddle wrote:On Saturday, 18 January 2014 at 19:40:38 UTC, Xavier Bigand wrote:I will try the global VAO. I already check glError with "checkgl!" function.I am not sure the issue come really from my code, cause it just works fine on ATI cards, I do something Nvidia drivers dislike. I tried to replace GL_LINE_LOOP by triangles, increase buffer size, put the GL_ELEMENT_ARRAY_BUFFER buffer type bind right before glDrawElements without success. Crash only append when I fill text mesh before those ones. So I need dig more.From what i saw in your code you are not using Vertex Array Objects. I have had similar problems that code ran fine on ATI but crashed on nvidia. The problem went away for me when i just created and bound a global VAO just after context creation. Also i would recommend calling glGetError after every call, it helps finding errors. Here is a simple trick to do this automatically. static gl { static ref auto opDispatch(string name, Args...)(Args args) { enum glName = "gl" ~ name[0].toUpper.to!string ~ name[1 .. $]; debug scope(exit) checkGLError(); //Do glGetError and log it or something. mixin("return " ~ glName ~ "(args);"); } } After this simply change all glFunctionName(args) to gl.functionName or gl.functionName.
Jan 22 2014
Le 22/01/2014 14:13, Flamaros a écrit :On Wednesday, 22 January 2014 at 02:11:02 UTC, TheFlyingFiddle wrote:I finally found the issue, glDisableVertexAttribArray calls were missing. I just doesn't understand why it works majority of times and any openGL debugging tool was able to warm me about that. Maybe I need try DirectX and see if debugging tools are better.On Saturday, 18 January 2014 at 19:40:38 UTC, Xavier Bigand wrote:I will try the global VAO. I already check glError with "checkgl!" function.I am not sure the issue come really from my code, cause it just works fine on ATI cards, I do something Nvidia drivers dislike. I tried to replace GL_LINE_LOOP by triangles, increase buffer size, put the GL_ELEMENT_ARRAY_BUFFER buffer type bind right before glDrawElements without success. Crash only append when I fill text mesh before those ones. So I need dig more.From what i saw in your code you are not using Vertex Array Objects. I have had similar problems that code ran fine on ATI but crashed on nvidia. The problem went away for me when i just created and bound a global VAO just after context creation. Also i would recommend calling glGetError after every call, it helps finding errors. Here is a simple trick to do this automatically. static gl { static ref auto opDispatch(string name, Args...)(Args args) { enum glName = "gl" ~ name[0].toUpper.to!string ~ name[1 .. $]; debug scope(exit) checkGLError(); //Do glGetError and log it or something. mixin("return " ~ glName ~ "(args);"); } } After this simply change all glFunctionName(args) to gl.functionName or gl.functionName.
Jan 29 2014
Ok, I can reproduce this, and it seems that the crash happens somewhere in no mans land. That means there is no debugging information present and the stack frame isn't valid either. So the debugger and druntimes buildin stacktrace code has no chance. My guess would be that this happens inside druntime or phobos. So to debug this issue you will have to build a debug version of druntime and phobos (just modify the DFLAGS variable inside the .mak files accordingly and build them using the digital mars make). And then link against these debug versions (using the -debuglib switch). I would recommend renaming the debug versions so you can use them whenever needed. I will take a deeper look tomorrow. Kind Regards Benjamin Thaut
Jan 11 2014
On Saturday, 11 January 2014 at 16:24:08 UTC, Xavier Bigand wrote:I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?In a perfect world D would have a built-in solution to avoid null references/pointer. :)
Jan 11 2014
Le 11/01/2014 17:24, Xavier Bigand a écrit :I get some troubles to solve a memory bug, just cause I don't have any informations for debuggers and I can't neither use DrMemory. Is it possible to get the callstack when calling a method on a null pointer with specifics DMD flags? Maybe DMD need add null ptr call checks in debug mode?I am using VisualD with cv2pdb. I also tried to put checks manually on the code section which seems to crash (no crash when commented), but I almost don't use ptr and it never enter in my check conditions. It's like a real memory corruption in an other part of code.
Jan 11 2014