Interestingly I just noticed this line: NVIDIA (R) CUDA Debugger 4.2 release Portions Copyright (C) 2007-2012 NVIDIA Corporation GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/bin/python...(no debugging symbols found)...done. (cuda-gdb)
"Reading symbols from /usr/bin/python...(no debugging symbols found)...done" I can use gdb instead of cuda-gdb and it finds the debugging symbols... but cuda-gdb is clueless. Though Im not sure whether that is relevant to this issue. -Matthias On Tue, Oct 2, 2012 at 4:01 PM, Matthias Lee <[email protected]>wrote: > Hi Andreas, > > Thanks for the reply, > I do get the debug output referencing the log/tmp files. > How do I tell cuda-gdb to pickup those files? > > Thanks, > > Matthias > > > On Mon, Oct 1, 2012 at 3:51 PM, Andreas Kloeckner <[email protected] > > wrote: > >> Matthias Lee <[email protected]> writes: >> >> > Hello, >> > >> > I started using pycuda with cuda-gdb to debug a project im currently >> > working on. >> > I cant seem to get any backtrace/source. >> > Is there a way to tell pycuda to compile with debug symbols? >> >> -m pycuda.debug should do that. >> >> > $> cuda-gdb --args python -m pycuda.debug <project.py> >> >> (cuda-gdb) set cuda memcheck on >> >> (cuda-gdb) run >> >> <program output> >> >> [Launch of CUDA Kernel 80 (ola_Kernel_test<<<(37,37,1),(16,16,1)>>>) on >> >> Device 0] >> >> Program received signal CUDA_EXCEPTION_1, Lane Illegal Address. >> >> [Switching focus to CUDA kernel 80, grid 81, block (0,33,0), thread >> >> (0,12,0), device 0, sm 4, warp 14, lane 0] >> >> 0x0000000003780250 in ola_Kernel_test<<<(37,37,1),(16,16,1)>>> () >> >> (cuda-gdb) bt >> >> #0 0x0000000003780250 in ola_Kernel_test<<<(37,37,1),(16,16,1)>>> () >> >> (cuda-gdb) >> > >> > >> > Also interestingly when I put a break point at the kernel it will give >> me >> > the wrong file name with the correct line number >> > >> > (cuda-gdb) break ola_Kernel_test >> >> Breakpoint 1 at 0x2987870: file kernel.cu, line 297. (20 locations) >> >> (cuda-gdb) >> > >> > >> > kernel.cu contains no "ola_Kernel_test" but gputools.cu does at line >> 297 >> >> PyCUDA calls the file it compiles 'kernel.cu'. That lives in some >> directory in /tmp. It seems to vary whether the path to that file gets >> baked into the source--sometimes it does, sometimes it doesn't... In any >> case, if debugging is properly enabled, then you should also get a message >> >> *** compiler output in /tmp/something/or/another >> >> If you can then tell gdb where to look for kernel.cu, that should allow >> you to find the source. >> >> -m pycuda.debug should turn on that message, in addition to telling >> PyCUDA to not delete these files after it's done with them, so that the >> debugger can find them. (If not, that's a bug, please report.) >> >> HTH, >> Andreas >> > > > > -- > Matthias Lee > SDSS/Johns Hopkins University > Performance @ Rational/IBM > > [email protected] > [email protected] > (320) 496 6293 > > To know recursion, you must first know recursion. > > -- Matthias Lee SDSS/Johns Hopkins University Performance @ Rational/IBM [email protected] [email protected] (320) 496 6293 To know recursion, you must first know recursion.
_______________________________________________ PyCUDA mailing list [email protected] http://lists.tiker.net/listinfo/pycuda
