Le 11/01/2014 22:15, Benjamin Thaut a écrit :
> 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

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.

Am 11.01.2014 22:56, schrieb Xavier Bigand:
> Le 11/01/2014 22:15, Benjamin Thaut a écrit :
>> 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
>
> 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.

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 Thaut

Le 12/01/2014 00:30, Benjamin Thaut a écrit :
> Am 11.01.2014 22:56, schrieb Xavier Bigand:
>> Le 11/01/2014 22:15, Benjamin Thaut a écrit :
>>> 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
>>
>> 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.
>
> 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 Thaut

I didn't know this menu settings, but activate Access Violation don't change anything.

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

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

Le 12/01/2014 11:16, Benjamin Thaut a écrit :
> 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

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.

Am 12.01.2014 17:18, schrieb Xavier Bigand:
> Le 12/01/2014 11:16, Benjamin Thaut a écrit :
>> 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
>
> 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 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 Thaut

Le 12/01/2014 18:01, Benjamin Thaut a écrit :
> Am 12.01.2014 17:18, schrieb Xavier Bigand:
>> Le 12/01/2014 11:16, Benjamin Thaut a écrit :
>>> 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
>>
>> 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 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 Thaut

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 nsight

Le 13/01/2014 20:42, Xavier Bigand a écrit :
> Le 12/01/2014 18:01, Benjamin Thaut a écrit :
>> Am 12.01.2014 17:18, schrieb Xavier Bigand:
>>> Le 12/01/2014 11:16, Benjamin Thaut a écrit :
>>>> 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
>>>
>>> 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 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 Thaut
>
> 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 nsight

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 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