gDebugger crash on pause?

Started by
4 comments, last by noodleBowl 9 years, 5 months ago

I was wondering if anyone has run into this issue before and has a fix.

I'm trying to use gDebugger 6.2 and I have the latest ATI drivers for my card, but any time I try to use gDebugger on my application and pause it, it auto crashes :(

I get a second chance exception:


Exception
Event Properties
Reason   
Access violation
Address   
0x0027be94
Details   
The thread tried to read from or write to a virtual address to which it does not have access.

Where the last line of the call stack was


RtlInitializeExceptionChain - ntdll.dll

Call Stack
Function Name   
RtlInitializeExceptionChain
File Path   
N/A
Line Number   
N/A
Module Name   
C:\Windows\SysWOW64\ntdll.dll
Instruction Counter Address   
0x77de9f71
Function address   
0x77de9f0f

I'm hitting the debug version of my project, also I'm using SDL2 for window creation and GLEW for the extensions

Anyone got any ideas ? That or another openGL debugger tool

Thanks!

Advertisement

Is there a reason you're not using AMD CodeXL? AMD gDEBugger has been succeeded by AMD’s CodeXL.

Derp

I could never get CodeXL to work with OpenGL programs. It seems to be geared more towards OpenCL and GPGPU. For OpenGL, I recommend GPU PerfStudio

I tried using both tools!

I really like the feel of AMD CodeXL and I was super surprised it worked, but I really do have to agree with Xycaleth. It definitely feels like its more geared towards openCL.

When it comes to GPU PrefStudio, I like it a lot but I'm a little concerned when I open up the API trace and see my glMapBufferRange call is being flagged as using GL_MAP_READ_BIT | GL_MAP_WRITE_BIT in the parameters section. Especially when I am definitely only using GL_MAP_WRITE_BIT in my code. I kind of thought this was a fluke, but when I change my glClear call to only use GL_COLOR_BUFFER_BIT it reflects. So it makes me wonder what other calls are going to be treated like this or how bad it effects the call timings. Maybe the params are being overridden cause of the frame capture / application analysis?

Also in the Frame Profiler tab it says my GPU Busy time is 0%, which I find odd. But this may be true since my test app only maps 10K quads and calls glDrawElements once per frame

As a one last thing I get a verdict of "Application is bound by draw operations. But the GPU is not fully utilized", can someone explain this to me :)?

Is what I think it means, that I have hit or are hitting my fillrate limit? I'm only doing one draw call per frame and my shaders are not fancy at all, so the "bound by draw operation" part is throwing me off

Which version of OpenGL are you using? I get the same problem as well with the MapBufferRange bits being wrong! I'm using the write and unsynchronized bits but Perf Studio says I'm using the read bit as well. I put it down to me using GL 4.4 but Perf Studio only supporting up to 4.3.

I know right! Its very confusing.

I'm using SDL and targeting OpenGL 3.3, so I think that would be covered unless it really only supports OpenGL 4.3, but that would just be ridiculous

Does the frame debugger crash for you? My program always dies as soon as I hit that button

This topic is closed to new replies.

Advertisement