Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 22/01/2014 14:13, Flamaros a écrit :
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 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.
I will try the global VAO.
I already check glError with checkgl! function.
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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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 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.
I will try the global VAO.
I already check glError with checkgl! function.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 13/01/2014 22:47, Benjamin Thaut a écrit : 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,) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4 -glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) --glUseProgram(4) --glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00]) -glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) --glBindBuffer(GL_ARRAY_BUFFER,10) --glEnableVertexAttribArray(0) --glVertexAttribPointer(0,3,GL_FLOAT,false,12,) --glBindBuffer(GL_ARRAY_BUFFER,11) --glEnableVertexAttribArray(1) --glVertexAttribPointer(1,4,GL_FLOAT,false,16,) --glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) 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,) --glBindBuffer(GL_ARRAY_BUFFER,11) --glEnableVertexAttribArray(1) --glVertexAttribPointer(1,4,GL_FLOAT,false,16,0016) --glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,0004) 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 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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00])
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9)
glBindBuffer(GL_ARRAY_BUFFER,10)
glEnableVertexAttribArray(0)
glVertexAttribPointer(0,3,GL_FLOAT,false,12,)
glBindBuffer(GL_ARRAY_BUFFER,11)
glEnableVertexAttribArray(1)
glVertexAttribPointer(1,4,GL_FLOAT,false,16,)
glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4
-glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT)
--glUseProgram(4)
--glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00])
-glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9)
--glBindBuffer(GL_ARRAY_BUFFER,10)
--glEnableVertexAttribArray(0)
--glVertexAttribPointer(0,3,GL_FLOAT,false,12,)
--glBindBuffer(GL_ARRAY_BUFFER,11)
--glEnableVertexAttribArray(1)
--glVertexAttribPointer(1,4,GL_FLOAT,false,16,)
--glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) 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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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,) glBindBuffer(GL_ARRAY_BUFFER,11) glEnableVertexAttribArray(1) glVertexAttribPointer(1,4,GL_FLOAT,false,16,) glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) GLSL=4 -glClear(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) --glUseProgram(4) --glUniformMatrix4fv(0,1,false,[0.002497,0.00,0.00,0.00,0.00,-0.00,0.00,0.00,0.00,0.00,-0.01,0.00,-1.00,1.00,0.00,1.00]) -glBindBuffer(GL_ELEMENT_ARRAY_BUFFER,9) --glBindBuffer(GL_ARRAY_BUFFER,10) --glEnableVertexAttribArray(0) --glVertexAttribPointer(0,3,GL_FLOAT,false,12,) --glBindBuffer(GL_ARRAY_BUFFER,11) --glEnableVertexAttribArray(1) --glVertexAttribPointer(1,4,GL_FLOAT,false,16,) --glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,) 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,) --glBindBuffer(GL_ARRAY_BUFFER,11) --glEnableVertexAttribArray(1) --glVertexAttribPointer(1,4,GL_FLOAT,false,16,0016) --glDrawElements(GL_LINE_LOOP,4,GL_UNSIGNED_INT,0004) 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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
[Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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?
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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. :)
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 11/01/2014 18:20, Namespace a écrit : 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 Doesn't change anything.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 11/01/2014 18:45, Benjamin Thaut a écrit : 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 Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Am 11.01.2014 19:16, schrieb Xavier Bigand: Le 11/01/2014 18:45, Benjamin Thaut a écrit : 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 Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g. 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 Thaut
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
Le 11/01/2014 19:40, Benjamin Thaut a écrit : Am 11.01.2014 19:16, schrieb Xavier Bigand: Le 11/01/2014 18:45, Benjamin Thaut a écrit : 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 Yep I am using VisualD with cv2pdb, and I build in debug mode with the flag -g. 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 Thaut Yes I have no stack trace and adding import core.sys.windows.stacktrace change nothing.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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.
Re: [Windows DMD] No callstack when crash with Access violation reading location 0x00000000
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
