Archives Discussions

[theblang]

I feel like this may be a dumb question, but I can't seem to get the gDEBugger to work.  I have installed the add-on for VS10 and can select the start debugging option from the gDEBugger drop down menu.  When I do this I see some stuff on the output window and then the program exits.  I tried setting new breakpoints, but this does nothing.  I never saw the screen that, according to AMD, was supposed to pop up in order for me to obtain a complimentary license.  Do I need to do something with my project properties to get the gDEBugger to work with it?

[amhagan]

Not a dumb question at all.  The VS2010 version of gDEBugger is a seems to be somewhat unstable. You would probably be better off downloading the 5.8 version from http://www.gremedy.com/.

But to answer your question do you have dlls that your project is trying to load outside of the exe execution path? For example, in one of my projects properties under "Configuration Properties" -> "Debugging" for the "Environment"  setting. I set PATH=$(TsRuntimePath);%PATH% where TsRuntimePath is set in the  UserMacros of the PropertySheet.  GDEBugger is not able to resolve this and I get the same results that you do (gDEBugger trying to start and exiting).

Your other option is to set the path up at the system level so that when gDEBugger runs via VS2010 it is able to find and load all the project deps..

Hope it helps.

[theblang]

My project does not use any dynamic libraries, but I am using another static lib (besides the AMD APP) called GLUT.  Could this be something to do with it you think?

I am not sure exactly what you mean by setting the PATH up at the system level.  I have, of course, set the additional libraries and include directories, in my VS2010 project properties, to point to my include and lib folders containing the GLUT library.

Just to give a little additional information, if I scroll up as far as I can in the output I see a bunch of messages stating that certain DLLs were loaded/unloaded, that a thread was created, that the program exited with code 0, and the thread and process terminated.

[theblang]

As an update, I downloaded the standalone gDEBugger from gremedy.  It does the exact same thing.  I am using the C++ wrapper for my openCL setup on the host side.  I was assuming that functions like clBuildProgram were called within the wrapper.  Am I wrong in assuming this?  If I set a breakpoint for say, clBuildProgram, but really I am using the C++ cl::Program object, will it still try to break?

In both the standalone and VS2010 add-on the debugging just doesn't seem to break, which makes me think that perhaps I haven't set up something correctly.  I don't see a list of my kernel functions like in the sample teapot project.

[theblang]

I figured out part of the issue.  I made a brand new project and rewrote my code (using C functions instead of the C++ bindings, though, I don't think this was an issue as I tested the debugger on a C++ binding call and it did correctly break at the C function inside the C++ wrapper).  The breakpoints are now working perfectly for API function calls and the kernel function.  The problem was that I was calling enqueueNDRangeKernel inside of a GLUT callback function.  Apparently the debugger can't detect the kernel function when I do this.

[theblang]

Sorry, not trying to spam.  This will be my last message unless someone has an idea of what could be the problem.  Unfortunately, the debugger has started doing the same thing.  It is as if no breakpoints are set, and it just exits with code 0.  As I mentioned in an earlier reply, I had completely rewrote my code and it seemed to be working.  I am not sure what is causing this.