Debug a DLL with Python

[simbalsyd]

Hi

I have a DLL created by Code::Blocks and it works fine with Python 2.7. Sometimes it would be nice to debug the DLL but I can't figure out how to do it. Any ideas on how to do it?

I am compiling with GCC and I use Windows XP and Windows 7.


Best regards
Anders

[oBFusCATed]

Have you tried Debug->Attach to process?

[simbalsyd]

Yes I tried to attach to the Python process but maybe I should attach to another process?

/Anders

[renega_666]

What happened when you tried to attach to the python process? Is your dll compiled with debug informations?

I debug my python extensions using codblocks and attach to process without any troubles on windows xp, windows 7 and GNU/Linux.

[simbalsyd]

The dll is built with "Produce debugging symbols" -g

Do I need to set more options?


When I attach to the Python process I get the following:

Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Reading symbols from C:\Python27\python.exe...(no debugging symbols found)...done.
Debugger name and version: GNU gdb (GDB) 7.2

I have set a breakpoint and it seems like the debugger stops there (I guess from watching the console output)

When I click on "Debug / Continue" I get a segmentation fault:


Child process PID: 7588
Program received signal SIGSEGV, Segmentation fault.
In ntdll!RtlpWaitForCriticalSection () (C:\WINDOWS\system32\ntdll.dll)

The DLL works perfectly together with Python without the debugger.

Any ideas?

[oBFusCATed]

You have to post the full log from the debugger.

[simbalsyd]

I think that was everything in the Debug log window but today the last line in the debug log says:

   In ntdll!KiIntSystemCall () (C:\WINDOWS\system32\ntdll.dll)

Maybe the content in the Disassembly window can say something. Here it is:


7C9520EC   push   $0x8
7C9520EE   push   $0x7c952138
7C9520F3   call   0x7c90e8cb <strchr+190>
7C9520F8   mov    %fs:0x18,%eax
7C9520FE   mov    0x30(%eax),%eax
7C952101   cmpb   $0x0,0x2(%eax)
7C952105   jne    0x7c952110 <ntdll!KiIntSystemCall+36>
7C952107   testb  $0x2,0x7ffe02d4
7C95210E   je     0x7c952130 <ntdll!KiIntSystemCall+68>
7C952110   andl   $0x0,-0x4(%ebp)
7C952114   call   0x7c90120e <ntdll!DbgUiConnectToDbg>
7C952119   jmp    0x7c95212c <ntdll!KiIntSystemCall+64>
7C95211B   nop
7C95211C   nop
7C95211D   nop
7C95211E   nop
7C95211F   nop
7C952120   xor    %eax,%eax
7C952122   inc    %eax
7C952123   ret
7C952124   nop
7C952125   nop
7C952126   nop
7C952127   nop
7C952128   nop
7C952129   mov    -0x18(%ebp),%esp
7C95212C   orl    $0xffffffff,-0x4(%ebp)
7C952130   push   $0x0
7C952132   call   0x7c9640cb <ntdll!RtlExtendedLargeIntegerDivide>
7C952137   nop
7C952138   (bad)
7C952139   (bad)
7C95213A   (bad)
7C95213B   jmp    *(%eax)
7C95213D   and    %edx,-0x6aded684(%ebp)
7C952143   jl     0x7c9520d5 <ntdll!KiUserApcDispatcher+11>
7C952145   nop
7C952146   nop
7C952147   nop
7C952148   nop


/Anders

[oBFusCATed]

Doesn't help. Paste the full log. See the settings for details how to enable it.

[simbalsyd]

I found the setting. This is the result:


Command-line: C:\MinGW\bin\gdb.exe -nx -fullname  -quiet -pid=6500
Working dir : Q:\AK96\Tools\ufs\unittests\dll\
> set prompt >>>>>>cb_gdb:
Attaching to process 6500
[New Thread 6500.0x1b48]
[New Thread 6500.0x16c4]
Reading symbols from C:\Python27\python.exe...(no debugging symbols found)...done.
[Switching to Thread 6500.0x16c4]
(gdb) >>>>>>cb_gdb:
> show version
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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source C:\Program Files\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> run
ContinueDebugEvent (cpid=6500, ctid=16c4, DBG_CONTINUE);
ContinueDebugEvent (cpid=6500, ctid=1b48, DBG_CONTINUE);
ContinueDebugEvent (cpid=6500, ctid=16c4, DBG_CONTINUE);
gdb: windows_close, inferior_ptid=6500
gdb: windows_init_thread_list
[New Thread 3940.0x4e8]
Program received signal SIGSEGV, Segmentation fault.
0x7c919af2 in ntdll!RtlpWaitForCriticalSection () from C:\WINDOWS\system32\ntdll.dll
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> bt 30
#0  0x7c919af2 in ntdll!RtlpWaitForCriticalSection () from C:\WINDOWS\system32\ntdll.dll
#1  0x7c901046 in ntdll!RtlEnumerateGenericTableLikeADirectory () from C:\WINDOWS\system32\ntdll.dll
#2  0x00e461a0 in ?? ()
#3  0x77dd6cf8 in RegCloseKey () from C:\WINDOWS\system32\advapi32.dll
#4  0x77dd78e4 in RegOpenKeyExA () from C:\WINDOWS\system32\advapi32.dll
#5  0x622915bb in ?? () from C:\PROGRA~1\NetInst\NiAMH.dll
#6  0x62291143 in ?? () from C:\PROGRA~1\NetInst\NiAMH.dll
#7  0x62292778 in ?? () from C:\PROGRA~1\NetInst\NiAMH.dll
#8  0x62292820 in ?? () from C:\PROGRA~1\NetInst\NiAMH.dll
#9  0x7c90118a in ntdll!LdrSetAppCompatDllRedirectionCallback () from C:\WINDOWS\system32\ntdll.dll
#10 0x62290000 in ?? ()
#11 0x7c91b5d2 in ntdll!LdrHotPatchRoutine () from C:\WINDOWS\system32\ntdll.dll
#12 0x7c9162db in ntdll!RtlValidateUnicodeString () from C:\WINDOWS\system32\ntdll.dll
#13 0x7c91643d in ntdll!LdrShutdownProcess () from C:\WINDOWS\system32\ntdll.dll
#14 0x00000000 in ?? ()
>>>>>>cb_gdb:

[oBFusCATed]

What compiler is used to build python? I guess Visual studio?

[simbalsyd]

Hi

I checked and it is built with Microsoft Visual C++.

/Anders

[oBFusCATed]

So, most probably you have to build your extension with Visual C++ and the versions must match.
Another option is to use python built by gcc/mingw.
Mixing compilers rarely work correctly.

[renega_666]

Insert Quote
So, most probably you have to build your extension with Visual C++ and the versions must match.
Another option is to use python built by gcc/mingw.
Mixing compilers rarely work correctly.

I have a project where I always build python extensions with mingw and codeblocks. I can debug and use them on a regular python installation (compiled with visual studio) without any problems. So the problem might actually be somewhere else.

I remember I had some problems to debug python extensions a while ago with an old nightly build ( before the debug branch merge ) but with a recent nightly it definitely works. Never tested with 10.05.

Here is my setup:
- IDE: Codeblocks r8248
- Compiler: TDM-GCC 4.6.1
- Python version: 2.7.3 compiled with VC9
- Windows XP SP3 & Windows 7 SP1