Code::Blocks Forums
User forums => Using Code::Blocks => Topic started by: simbalsyd on September 05, 2012, 08:08:25 am
-
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
-
Have you tried Debug->Attach to process?
-
Yes I tried to attach to the Python process but maybe I should attach to another process?
/Anders
-
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.
-
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?
-
You have to post the full log from the debugger.
-
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
-
Doesn't help. Paste the full log. See the settings for details how to enable it.
-
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:
-
What compiler is used to build python? I guess Visual studio?
-
Hi
I checked and it is built with Microsoft Visual C++.
/Anders
-
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.
-
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