cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

Meteorhead
Challenger

gDEBugger crash

I have started using the new gDEBugger under Win7 64-bit with newest Catalyst drivers, and there are two cases, where the tool crashes.

My application uses a custom made cl::Runtime class that enumerates all platforms, and devices that exist on the running machine, and it also creates one context for every vendor with CL_DEVICE_TYPE_ALL as a parameter (as it should work ultimately). Since I have an intel platform installed beside AMD (processor is Core-i5 430M). Problem is, when it tries to create the Intel context, the tool crashes. Later on in the application, I don't intend on using it, but the init() function of my Runtime class automatically creates this context. I do not expect gDEBugger to be able debug kernels running on an Intel CPU or IGP, but hey... I don't think my expectations are high if I want gDEBugger to outlive such a function call. Right now I got my class bypass enumerating the Intel platform, but clearly this is not a real solution.

Second issue: as I was writing about the second issue and looked deeper into the code I saw what is the source of it, and I managed to solve it, however I do not understand why the problem exists. All functions that do not explicitly specify a context use the _getDefault() function inside the wrapper. When the gDEBugger meets this functions (default cl::flush() function, or a cl::Buffer constructor with first argument as default...) it simply crashes. Why is this?

0 Likes
5 Replies

Hi Meteorhead,

A few things are unclear about the problems you're having, could you clarify?

1. Are you using gDEBugger 6.1 or 6.2? gDEBugger 6.2 contained a fix to a bug that looks a lot like what you describe in #2.

2. When you are experiencing these problems, is there a gDEBugger dialog that pops up asking you to send the error report? If so, could you select to send it? If that is not possible (internal network or firewall limitations), please copy the details from the "click here to show details" options and post them here.

3. About the first crash: Do you know what is the specific function that causes the crash? From what you're writing, I'd guess it's clCreateContextFromType. Could you put a gDEBugger breakpoint on that function, and after it's hit take note of what appears in the gDEBugger API calls history view (i.e. the function parameter list), do a single step over (F10) and see if that crashes (or if the crash is after a later function.

4. About the second crash: same question, I'd guess the functions in question are clFlush and clCreateBuffer.

0 Likes

Hi Uri,

Edit: I forgot, gDEBugger was intalled from AMDgDEBugger6.2.865x64.msi

I have already sent these reports when the dialog window popped up. However, here are some screens that might help uncover the source of the problem: First two images are about first crash with breakpoint set to clCreateContextFromType, second two images are about second crash, breakpoint set to clFlush, but the crash occurs before that, inside the c++ wrapper of OpenCL.

crash1 - 1.pngcrash1 - 2.pngcrash2 - 1.pngcrash2 - 2.png

0 Likes

Looking at the call stacks for these crashes, it seems that in your code, the function cl::Context::getDefault() creates the default context if it does not exist yet - so all instances are the same issue of a crash when a context is created.

To enable kernel debugging, we change the context properties on creation, perhaps other vendors have ICD modules that do not know to ignore unknown context properties.

Your report does not appear in out systems for some reason, could you paste the contents of the "click here to show details" dialog as a post here?

Thanks,

0 Likes

I did ot find the part you talked about, but I hope this is what you meant:

What were you doing when the problem happened (optional)?

N/A

Email address (optional):

N/A

Operating System:

Win7-64

Call stack:

Function name - File path - Line number - Module path - Function Start address - Module Start address - Instruction counter address

clGetContextInfo - N/A - N/A - C:\Windows\System32\IntelOpenCL64.dll - 0x000007feed592a40 - 0x000007feed590000 - 0x000007feed592ae4

clGetContextInfo - N/A - N/A - C:\Windows\System32\OpenCL.dll - 0x000007feefef1630 - 0x000007feefef0000 - 0x000007feefef1651

csContextMonitor::updateOpenCLContextCreationProperties - d:\jenkins\workspace\gdebuggerreleasebranch-6.2\release\gdebugger\6.2\gdebugger\workspaces\gropenclservers\src\cscontextmonitor.cpp - 635 - C:\Kellekek\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\AMD\gDEBugger\spies64\OpenCL.dll - 0x000007feebb34f60 - 0x000007feebb20000 - 0x000007feebb34f93

csContextMonitor::updateOpenCLContextObjectInfo - d:\jenkins\workspace\gdebuggerreleasebranch-6.2\release\gdebugger\6.2\gdebugger\workspaces\gropenclservers\src\cscontextmonitor.cpp - 549 - C:\Kellekek\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\AMD\gDEBugger\spies64\OpenCL.dll - 0x000007feebb34d80 - 0x000007feebb20000 - 0x000007feebb34db4

csContextMonitor::csContextMonitor - d:\jenkins\workspace\gdebuggerreleasebranch-6.2\release\gdebugger\6.2\gdebugger\workspaces\gropenclservers\src\cscontextmonitor.cpp - 52 - C:\Kellekek\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\AMD\gDEBugger\spies64\OpenCL.dll - 0x000007feebb34370 - 0x000007feebb20000 - 0x000007feebb34519

csOpenCLMonitor::onContextCreation - d:\jenkins\workspace\gdebuggerreleasebranch-6.2\release\gdebugger\6.2\gdebugger\workspaces\gropenclservers\src\csopenclmonitor.cpp - 235 - C:\Kellekek\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\AMD\gDEBugger\spies64\OpenCL.dll - 0x000007feebb45870 - 0x000007feebb20000 - 0x000007feebb458ed

clCreateContextFromType - d:\jenkins\workspace\gdebuggerreleasebranch-6.2\release\gdebugger\6.2\gdebugger\workspaces\gropenclservers\src\csopenclwrappers.cpp - 306 - C:\Kellekek\Microsoft Visual Studio 10.0\Common7\IDE\Extensions\AMD\gDEBugger\spies64\OpenCL.dll - 0x000007feebb4ada0 - 0x000007feebb20000 - 0x000007feebb4ae87

cl::Context::getDefault - c:\program files (x86)\amd app\include\cl\cl.hpp - 1707 - D:\ToBeSaved\Develop\gripper\bin\gripper.exe - 0x000000013f451bb0 - 0x000000013f450000 - 0x000000013f451c8e

cl::CommandQueue::getDefault - c:\program files (x86)\amd app\include\cl\cl.hpp - 3193 - D:\ToBeSaved\Develop\gripper\bin\gripper.exe - 0x000000013f451e80 - 0x000000013f450000 - 0x000000013f451f13

Gripper::runSim - d:\tobesaved\develop\gripper\include\gripper.hpp - 548 - D:\ToBeSaved\Develop\gripper\bin\gripper.exe - 0x000000013f456550 - 0x000000013f450000 - 0x000000013f45659e

sf::priv::ThreadImpl::entryPoint - N/A - N/A - D:\ToBeSaved\Develop\gripper\bin\gripper.exe - 0x000000013f468a00 - 0x000000013f450000 - 0x000000013f468a08

_callthreadstartex - f:\dd\vctools\crt_bld\self_64_amd64\crt\src\threadex.c - 314 - D:\ToBeSaved\Develop\gripper\bin\gripper.exe - 0x000000013f54d18c - 0x000000013f450000 - 0x000000013f54d1a2

_threadstartex - f:\dd\vctools\crt_bld\self_64_amd64\crt\src\threadex.c - 292 - D:\ToBeSaved\Develop\gripper\bin\gripper.exe - 0x000000013f54d1b8 - 0x000000013f450000 - 0x000000013f54d236

BaseThreadInitThunk - N/A - N/A - C:\Windows\System32\kernel32.dll - 0x00000000776e6520 - 0x00000000776d0000 - 0x00000000776e652c

N/A - N/A - N/A - N/A - N/A - N/A - N/A

System DLL Versions:

- atioglxx.dll: 6.14.10.11631

- atio6axx.dll: 6.14.10.11631

- aticfx32.dll: 8.17.10.1124

- aticfx64.dll: 8.17.10.1124

- aticaldd.dll: 6.14.10.1720

- OpenCL.dll: 1.2.1.0

OpenGL Renderer:

- Renderer Vendor: ATI Technologies Inc.

- Renderer Name: ATI Mobility Radeon HD 5800 Series

- Renderer Version: 4.2.11631 Compatibility Profile Context

- Renderer Type: Installable client

Drivers versions:

- CAL version: 1.4.1720

- Catalyst version: 12.4

Device 1 (CPU):

- Platform ID: 1

- Device Type: CPU

- Device Name: Intel(R) Core(TM) i5 CPU       M 430  @ 2.27GHz

- Vendor: Intel(R) Corporation

Device 2 (GPU):

- Platform ID: 2

- Device Type: GPU

- Device Name: Juniper

- Vendor: Advanced Micro Devices, Inc.

Device 3 (CPU):

- Platform ID: 2

- Device Type: CPU

- Device Name: Intel(R) Core(TM) i5 CPU       M 430  @ 2.27GHz

- Vendor: GenuineIntel

Platform 1:

- Vendor: Intel(R) Corporation

- Name: Intel(R) OpenCL

- Profile: FULL_PROFILE

- Version: OpenCL 1.1

Platform 2:

- Vendor: Advanced Micro Devices, Inc.

- Name: AMD Accelerated Parallel Processing

- Profile: FULL_PROFILE

- Version: OpenCL 1.2 AMD-APP (923.1)

Additional Information:

- OpenCL Engine loaded:Yes

- OpenGL Engine loaded:Yes

- Kernel Debugging Entered:No

Cheers,

Máté

0 Likes

This indeed seems to be a problem in the other platform's OpenCL module, possibly related to the aforementioned context property.

We're looking into making sure that these added properties do not get added for contexts on platforms other than the AMD platform.

Could you please try the following, outside of the bindings and outside gDEBugger (i.e. run with F5), just to verify if that is indeed the crash location:

int testFunc(cl_event, cl_int*)
{
    return 1;
}

{
...
    cl_context_properties cp[7 + 2] = { ... , ... ,
                                       (cl_context_properties)0x403D, (cl_context_properties)(&testFunc),
                                       (cl_context_properties)0}; // Add the last two properties to your own properties

    cl_context ctx = clCreateContextFromType(cp, ... , ... ); // All other parameters as in the crash scenario

    size_t ps = 0;
    cl_int ret = clGetContextInfo(ctx, CL_CONTEXT_PROPERTIES, 0, 0, &ps); // Either this line crashes ...
    if ((CL_SUCCESS == ret) && (0 < ps))
    {
        cl_context_properties* cp_get = (cl_context_properties*)malloc(ps);
        ret = clGetContextInfo(ctx, CL_CONTEXT_PROPERTIES, ps, (void*)cp_get, 0); // ... or this one does

        free(cp_get)
    }
}

0 Likes