Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: scarphin on March 30, 2015, 01:48:23 pm

Title: Frame issue with the debugger plugin
Post by: scarphin on March 30, 2015, 01:48:23 pm
I've compiled a 64-bit version of CB (svn10149) with a patched (some 64-bit friendly fixes) wxwidgets (2.8.12) on win7 x64. I've been using it for weeks without a single crash so far but I'm experiencing this weird debugger issue with frame numbers. The problem is the gdb/cdb debugger interprets the frame numbers incorrectly and sometimes debugger executes a 'frame ...' command and tries to switch to that undefined frame giving unexpected results. I'm using the word 'interpret' because this doesn't occur with a 32-bit build (same rev svn10149) of cb with the same project, same code, same settings, same gdb, same compiler, same everything... I believe this is something related to the 64-bit version. A screenshot below:
(http://i.imgur.com/z1LWG9c.jpg)

I also tried this with the gdb/mi plugin here -> http://forums.codeblocks.org/index.php?topic=16230.0 (http://forums.codeblocks.org/index.php?topic=16230.0)
The problem doesn't occur with gdb/mi, screenshot below:
(http://i.imgur.com/QDMpbRZ.jpg)

I'm aware that both gdb/cdb and gdb/mi plugins use different communication protocols and I believe the correct behavior with gdb/mi is a result of this fact but I really like to hunt down the incompability (I think) with gdb/cdb. Can someone point me in the direction of the code responsible for interpreting the gdb output? Is it the 'GDB_driver::ParseOutput' function or some regex? Thanks.

OS: Win7 x64
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on March 30, 2015, 09:20:50 pm
Post the full debugger log. Screenshots doesn't help much.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on March 31, 2015, 12:28:44 am
Sorry, I was too biased to think that this is a 64-bit problem. Anyway debug log for gdb/cdb:
Code
Active debugger config: GDB/CDB debugger:GDB
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding source dir: D:\coding\projects\misc\exCpp\
Adding source dir: D:\coding\projects\misc\exCpp\
Adding file: D:\coding\projects\misc\exCpp\bin\Debug\exCpp.exe
Changing directory to: D:/coding/projects/misc/exCpp/bin/Debug/
Set variable: PATH=.;C:\Tools\mingw\4.9.2\x64_seh\bin;C:\Tools\mingw\4.9.2\x64_seh;C:\Tools\mingw\x64_seh\bin;C:\Tools\mingw\x64_seh;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Java\jre7\bin;C:\Program Files\MATLAB\R2011b\runtime\win64;C:\Program Files\MATLAB\R2011b\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Git\cmd;C:\Tools\msys64\bin;C:\Tools\python\2.7\x64;C:\Tools\python\2.7\x64\Scripts;C:\Tools\perl\5.20.1\x64\bin;C:\Tools\perl\5.20.1\x64\site\bin;D:\coding\lib\qt\4.8.6\x64_mingw-4.9.2_seh\bin;D:\coding\lib\opencv\2.4.10\x64_mingw-4.9.2_seh\bin;C:\Program Files\MiKTeX\miktex\bin\x64;C:\Program Files\Doxygen\bin;C:\Program Files (x86)\Graphviz\bin;C:\Program Files (x86)\Nmap;C:\Program Files (x86)\GPAC

[debug]Command-line: C:\Tools\mingw\4.9.2\x64_seh\bin\gdb.exe -fullname -quiet  -args D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe
[debug]Working dir : D:\coding\projects\misc\exCpp\bin\Debug

Starting debugger: C:\Tools\mingw\4.9.2\x64_seh\bin\gdb.exe -fullname -quiet  -args D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe
done

[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!

Setting breakpoints

[debug]Reading symbols from D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.8.1
[debug]Copyright (C) 2014 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "x86_64-w64-mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.8.1

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> directory D:/coding/projects/misc/exCpp/
[debug]Source directories searched: D:/coding/projects/misc/exCpp;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break "D:/coding/projects/misc/exCpp/src/main.cpp:13"
[debug]Breakpoint 2 at 0x4014fa: file D:\coding\projects\misc\exCpp\src\main.cpp, line 13.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: D:\coding\projects\misc\exCpp\bin\Debug\exCpp.exe 

Child process PID: 2884

[debug][New Thread 2884.0x1254]
[debug]Breakpoint 2, testFunc (a_arg1=10, a_arg2=2) at D:\coding\projects\misc\exCpp\src\main.cpp:13
[debug]D:\coding\projects\misc\exCpp\src\main.cpp:13:185:beg:0x4014fa
[debug]>>>>>>cb_gdb:

At D:\coding\projects\misc\exCpp\src\main.cpp:13

[debug]> info args
[debug]a_arg1 = 10
[debug]a_arg2 = 2
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  testFunc (a_arg1=10, a_arg2=2) at D:\coding\projects\misc\exCpp\src\main.cpp:13
[debug]#1  0x0000000000401545 in main (argc=1, argv=0x3f2700) at D:\coding\projects\misc\exCpp\src\main.cpp:23
[debug]>>>>>>cb_gdb:
[debug]> frame 198815440
[debug]#0  0x0000000000000000 in ?? ()
[debug]>>>>>>cb_gdb:

#0  0x0000000000000000 in ?? ()

And for gdb/mi:
Code
Active debugger config: GDB/MI:Default
start debugger
Building to ensure sources are up-to-date
Selecting target: 
Debug
Adding file: D:\coding\projects\misc\exCpp\bin\Debug\exCpp.exe

[debug]PATH=.;C:\Tools\mingw\4.9.2\x64_seh\bin;C:\Tools\mingw\4.9.2\x64_seh;.;D:\coding\projects\sw\codeblocks\trunk\src\base\tinyxml;D:\coding\lib\wxwidgets\2.8.12\x64_tdm-4.9.2_seh\lib\gcc_dll;D:\coding\projects\sw\codeblocks\trunk\src\devel_64;C:\Tools\tdm\4.9.2\x64_seh\bin;C:\Tools\tdm\4.9.2\x64_seh;C:\Tools\mingw\x64_seh\bin;C:\Tools\mingw\x64_seh;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files (x86)\Java\jre7\bin;C:\Program Files\MATLAB\R2011b\runtime\win64;C:\Program Files\MATLAB\R2011b\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Git\cmd;C:\Tools\msys64\bin;C:\Tools\python\2.7\x64;C:\Tools\python\2.7\x64\Scripts;C:\Tools\perl\5.20.1\x64\bin;C:\Tools\perl\5.20.1\x64\site\bin;D:\coding\lib\qt\4.8.6\x64_mingw-4.9.2_seh\bin;D:\coding\lib\opencv\2.4.10\x64_mingw-4.9.2_seh\bin;C:\Program Files\MiKTeX\miktex\bin\x64;C:\Program Files\Doxygen\bin;C:\Program Files (x86)\Graphviz\bin;C:\Program Files (x86)\Nmap;C:\Program Files (x86)\GPAC

GDB path: C:\Tools\mingw\4.9.2\x64_seh\bin\gdb.exe
DEBUGGEE path: D:\coding\projects\misc\exCpp\bin\Debug\exCpp.exe
Command-line: C:\Tools\mingw\4.9.2\x64_seh\bin\gdb.exe -fullname  -quiet --interpreter=mi -args D:\coding\projects\misc\exCpp\bin\Debug\exCpp.exe
Working dir : D:\coding\projects\misc\exCpp\bin\Debug\
Starting debugger: 

[debug]Executing command: C:\Tools\mingw\4.9.2\x64_seh\bin\gdb.exe -fullname  -quiet --interpreter=mi -args D:\coding\projects\misc\exCpp\bin\Debug\exCpp.exe

done

[debug]Executor stopped
[debug]Debugger_GDB_MI::CommitBreakpoints
[debug]ActionsMap::Run -> starting action: 00000000151F1210 id: 1
[debug]BreakpointAddAction::m_initial_cmd = 10000000000
[debug]cmd==>10000000000-break-insert -f D:\coding\projects\misc\exCpp\src\main.cpp:13
[debug]ActionsMap::Run -> starting action: 0000000015840890 id: 2
[debug]cmd==>20000000000-exec-arguments 
[debug]output==>=thread-group-added,id="i1"
[debug]unparsable_output==>~"Reading symbols from D:\\coding\\projects\\misc\\exCpp\\bin\\Debug\\exCpp.exe..."
[debug]unparsable_output==>~"done.\n"
[debug]unparsable_output==>(gdb)
[debug]output==>10000000000^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014fa",func="testFunc(int, int)",file="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",fullname="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",line="13",thread-groups=["i1"],times="0",original-location="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp:13"}
[debug]notification event recieved!
[debug]BreakpointAddAction::OnCommandResult: 10000000000
[debug]BreakpointAddAction::breakpoint index is 1
[debug]BreakpointAddAction::Finishing1
[debug]BreakpointAddAction::destructor
[debug]unparsable_output==>(gdb)
[debug]output==>20000000000^done
[debug]unparsable_output==>(gdb)
[debug]ActionsMap::Run -> starting action: 0000000015712B60 id: 3
[debug]RunAction::OnStart -> -exec-run
[debug]cmd==>30000000000-exec-run
[debug]output==>=thread-group-started,id="i1",pid="5740"
[debug]output==>=thread-created,id="1",group-id="i1"
[debug]unparsable_output==>~"[New Thread 5740.0x1254]\n"
[debug]output==>30000000000^running
[debug]output==>*running,thread-id="all"
[debug]unparsable_output==>(gdb)
[debug]output==>=library-loaded,id="C:\\Windows\\SYSTEM32\\ntdll.dll",target-name="C:\\Windows\\SYSTEM32\\ntdll.dll",host-name="C:\\Windows\\SYSTEM32\\ntdll.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\kernel32.dll",target-name="C:\\Windows\\system32\\kernel32.dll",host-name="C:\\Windows\\system32\\kernel32.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\KernelBase.dll",target-name="C:\\Windows\\system32\\KernelBase.dll",host-name="C:\\Windows\\system32\\KernelBase.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!

Found child pid: 5740


[debug]notification event recieved!
[debug]RunAction success, the debugger is !stopped!
[debug]RunAction::Output - type: result
class: running
results:

[debug]Executor started
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\msvcrt.dll",target-name="C:\\Windows\\system32\\msvcrt.dll",host-name="C:\\Windows\\system32\\msvcrt.dll",symbols-loaded="0",thread-group="i1"
[debug]RunAction::destructor
[debug]output==>=library-loaded,id="C:\\Tools\\mingw\\4.9.2\\x64_seh\\bin\\libstdc++-6.dll",target-name="C:\\Tools\\mingw\\4.9.2\\x64_seh\\bin\\libstdc++-6.dll",host-name="C:\\Tools\\mingw\\4.9.2\\x64_seh\\bin\\libstdc++-6.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Tools\\mingw\\4.9.2\\x64_seh\\opt\\bin\\libgcc_s_seh-1.dll",target-name="C:\\Tools\\mingw\\4.9.2\\x64_seh\\opt\\bin\\libgcc_s_seh-1.dll",host-name="C:\\Tools\\mingw\\4.9.2\\x64_seh\\opt\\bin\\libgcc_s_seh-1.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Tools\\mingw\\4.9.2\\x64_seh\\opt\\bin\\libwinpthread-1.dll",target-name="C:\\Tools\\mingw\\4.9.2\\x64_seh\\opt\\bin\\libwinpthread-1.dll",host-name="C:\\Tools\\mingw\\4.9.2\\x64_seh\\opt\\bin\\libwinpthread-1.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\user32.dll",target-name="C:\\Windows\\system32\\user32.dll",host-name="C:\\Windows\\system32\\user32.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\gdi32.dll",target-name="C:\\Windows\\system32\\gdi32.dll",host-name="C:\\Windows\\system32\\gdi32.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\lpk.dll",target-name="C:\\Windows\\system32\\lpk.dll",host-name="C:\\Windows\\system32\\lpk.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\usp10.dll",target-name="C:\\Windows\\system32\\usp10.dll",host-name="C:\\Windows\\system32\\usp10.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\imm32.dll",target-name="C:\\Windows\\system32\\imm32.dll",host-name="C:\\Windows\\system32\\imm32.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\msctf.dll",target-name="C:\\Windows\\system32\\msctf.dll",host-name="C:\\Windows\\system32\\msctf.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\guard64.dll",target-name="C:\\Windows\\system32\\guard64.dll",host-name="C:\\Windows\\system32\\guard64.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\advapi32.dll",target-name="C:\\Windows\\system32\\advapi32.dll",host-name="C:\\Windows\\system32\\advapi32.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]notification event recieved!
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\SYSTEM32\\sechost.dll",target-name="C:\\Windows\\SYSTEM32\\sechost.dll",host-name="C:\\Windows\\SYSTEM32\\sechost.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\rpcrt4.dll",target-name="C:\\Windows\\system32\\rpcrt4.dll",host-name="C:\\Windows\\system32\\rpcrt4.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\psapi.dll",target-name="C:\\Windows\\system32\\psapi.dll",host-name="C:\\Windows\\system32\\psapi.dll",symbols-loaded="0",thread-group="i1"
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\version.dll",target-name="C:\\Windows\\system32\\version.dll",host-name="C:\\Windows\\system32\\version.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]notification event recieved!
[debug]output==>=library-loaded,id="C:\\Windows\\system32\\fltLib.dll",target-name="C:\\Windows\\system32\\fltLib.dll",host-name="C:\\Windows\\system32\\fltLib.dll",symbols-loaded="0",thread-group="i1"
[debug]notification event recieved!
[debug]output==>=breakpoint-modified,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004014fa",func="testFunc(int, int)",file="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",fullname="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",line="13",thread-groups=["i1"],times="1",original-location="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp:13"}
[debug]unparsable_output==>~"\nBreakpoint "
[debug]unparsable_output==>~"1, testFunc (a_arg1=10, a_arg2=2) at D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp:13\n"
[debug]unparsable_output==>~"\032\032D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp:13:185:beg:0x4014fa\n"
[debug]output==>*stopped,reason="breakpoint-hit",disp="keep",bkptno="1",frame={addr="0x00000000004014fa",func="testFunc",args=[{name="a_arg1",value="10"},{name="a_arg2",value="2"}],file="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",fullname="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",line="13"},thread-id="1",stopped-threads="all"
[debug]unparsable_output==>(gdb)
[debug]notification event recieved!
[debug]notification event recieved!
[debug]Executor stopped
[debug]ActionsMap::Run -> starting action: 00000000156D5570 id: 4
[debug]cmd==>40000000000-stack-info-frame
[debug]cmd==>40000000001-stack-list-frames 0 30
[debug]cmd==>40000000002-stack-list-arguments 1 0 30
[debug]output==>40000000000^done,frame={level="0",addr="0x00000000004014fa",func="testFunc",file="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",fullname="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",line="13"}
[debug]unparsable_output==>(gdb)
[debug]output==>40000000001^done,stack=[frame={level="0",addr="0x00000000004014fa",func="testFunc",file="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",fullname="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",line="13"},frame={level="1",addr="0x0000000000401545",func="main",file="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",fullname="D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp",line="23"}]
[debug]unparsable_output==>(gdb)
[debug]output==>40000000002^done,stack-args=[frame={level="0",args=[{name="a_arg1",value="10"},{name="a_arg2",value="2"}]},frame={level="1",args=[{name="argc",value="1"},{name="argv",value="0x3628e0"}]}]
[debug]unparsable_output==>(gdb)
[debug]GenerateBacktrace::OnCommandOutput: tuple size 2 stack=[frame={level=0,addr=0x00000000004014fa,func=testFunc,file=D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp,fullname=D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp,line=13},frame={level=1,addr=0x0000000000401545,func=main,file=D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp,fullname=D:\\coding\\projects\\misc\\exCpp\\src\\main.cpp,line=23}]
[debug]GenerateBacktrace::OnCommandOutput arguments
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on March 31, 2015, 09:25:48 am
This is definitely a bug and you'll have to debug it unfortunately.

There are two places where a frame command is issued:
1. gdb_commands.h:1185
2. gdb_driver.cpp:609

Put breakpoints there and inspect what happens. Probably you'll have to switch the types to something like uint64_t, because using int and long is unreliable. I guess in your env sizeof(unsigned long)==32==sizeof(int).

p.s. don't look at gdb/mi it has not been updated for a long time.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on March 31, 2015, 02:11:42 pm
Quote from: oBFusCATed on March 31, 2015, 09:25:48 am
There are two places where a frame command is issued:
1. gdb_commands.h:1185
2. gdb_driver.cpp:609
Ok I replaced the frame number variables to 'size_t' and it works for both 32-bit and 64-bit as 'size_t' corresponds to 'uint32' for 32-bit and 'uint64' for 64-bit.

Quote from: oBFusCATed on March 31, 2015, 09:25:48 am
I guess in your env sizeof(unsigned long)==32==sizeof(int).
AFAIK that is the case for mingw and msvc resulting from the Windows' ABI which I believe is quite unfortunate.

Quote from: oBFusCATed on March 31, 2015, 09:25:48 am
p.s. don't look at gdb/mi it has not been updated for a long time.
gdb/mi seems to be more stable than it currently looks and I think gdb/mi is the way to go. I may provide patches for added functionality and bug fixes. I don't have much experience with test cases but you've already provided an almost working plugin and many test cases to follow so I may add functionality first and then add test cases (I know it should be the opposite btw). I'll post my patches to the corresponding thread, it's up to you if you value them or not. ;)

I attached a patch demonstrating the necessary changes, thanks for your help.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on March 31, 2015, 02:43:01 pm
Quote from: scarphin on March 31, 2015, 02:11:42 pm
gdb/mi seems to be more stable than it currently looks and I think gdb/mi is the way to go. I may provide patches for added functionality and bug fixes. I don't have much experience with test cases but you've already provided an almost working plugin and many test cases to follow so I may add functionality first and then add test cases (I know it should be the opposite btw). I'll post my patches to the corresponding thread, it's up to you if you value them or not. ;)

I attached a patch demonstrating the necessary changes, thanks for your help.
I don't intend to do any work on the gdb/mi plugin before I can find some time to design a regression test system.
If there is not such system adding new features is extremely hard, because it is pretty easy to break old features.
Then you can fix the old feature, but you then break something else and you're running in circles wasting time.

This is the reason, I've left the plugin in a non-compilable state, so people are not wasting time trying to use it.
I have some more important tasks to finish first and probably then I'll try to continue working on it.

For the current patches, you can put them on github as a pull request, so they are not forgotten, but I don't intend to integrate them because of the aforementioned reasons.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on March 31, 2015, 02:45:23 pm
About the gdb/cli patch:

Can you replace the wxstring::format with the usage of operator<< and see if it works correctly?
The reason I'm asking this is that the different format specifiers can have different meanings on different OSes, so I think that operator<< will be safer.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on March 31, 2015, 04:10:08 pm
I too didn't like the format specifier defaulting to '%llu' for both 32-bit and 64-bit platforms but it looks like 'wxString' doesn't have an 'operator<<' defined for 'long long' type:
http://docs.wxwidgets.org/trunk/classwx_string.html#concat (http://docs.wxwidgets.org/trunk/classwx_string.html#concat)

What do you suggest?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on March 31, 2015, 09:13:22 pm
Use:
1. stringstream, not sure if it really good idea
2. SCNu64 defined in inttypes.h  -> str.Format(wxT("frame %" SCNu64), number) I'm not sure how portable is this
3. Use uint32_t for the frame number

If I were you I'd try 2 and 3 and if I couldn't make it will do it with 1.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on March 31, 2015, 09:39:50 pm
1- Me neither!
2- Will that be more portable than 'llu'?
3- That doesn't work already.

I think it will be best to stick with 'llu' for now until cb gets upgraded to a higher wxwidgets version in which wxstring has an operator<< for 'long long' type. Or conditional compilation?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on March 31, 2015, 11:44:08 pm
2. Yes, it should be more portable. Otherwise why they'll add a macro. Probably it is not implemented by vc++, but we don't care much about it anyway.
3. This will require more changes. Probably track where the original value for the frame index is taken from and see why it is a long instead of uint32.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 01, 2015, 12:10:51 am
Quote from: oBFusCATed on March 31, 2015, 11:44:08 pm
3. This will require more changes. Probably track where the original value for the frame index is taken from and see why it is a long instead of uint32.
Well, I think that is what needs to be done. I think I spoke too soon that it worked, it's broken again for no obvious reason. Another issue, looking at the wxstring documentation, it has an 'operator<<' defined for a 'wxlonglong_t' type. From my understanding of 'wxlonglong_t' definition, it is defined as 'long long' for 64-bit compilers matching the definition of 'size_t'. That means 'operator<<' with an argument of 'size_t' should work correctly on a wxstring object. Can you please point me to the piece of code where the frame info is parsed, is it 'GDB_driver::ParseOutput'?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 07, 2015, 12:22:50 am
Have you tried using a debugger to trace where bad value is generated from?

It is perfectly possible to debug cb, while debugging another application. It is a little odd, but works:)
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 07, 2015, 01:15:41 am
Yes, many times but I quit after getting errors like:
Code
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I don't know if it's CB related or something else but I can't deal with it. If you want to see the debug log:
Code
Active debugger config: GDB/CDB debugger:GDB
Building to ensure sources are up-to-date
Selecting target: 
Debugger
Adding source dir: D:\coding\projects\sw\codeblocks\trunk\src\
Adding source dir: D:\coding\projects\sw\codeblocks\trunk\src\
Adding file: .\codeblocks.exe
Changing directory to: D:/coding/projects/sw/codeblocks/trunk/src/devel_64
Set variable: PATH=.;D:\coding\projects\sw\codeblocks\trunk\src\base\tinyxml;D:\coding\lib\wxwidgets\2.8.12\x64_tdm-4.9.2_seh\lib\gcc_dll;D:\coding\projects\sw\codeblocks\trunk\src\devel_64;C:\Tools\tdm\4.9.2\x64_seh\bin;C:\Tools\tdm\4.9.2\x64_seh;C:\Tools\mingw\4.9.2\x64_seh\bin;C:\Tools\mingw\x64_seh\bin;C:\Tools\mingw\x64_seh;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files (x86)\Java\jre7\bin;C:\Program Files\MATLAB\R2011b\runtime\win64;C:\Program Files\MATLAB\R2011b\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Git\cmd;C:\Tools\msys64\bin;C:\Tools\python\2.7\x64;C:\Tools\python\2.7\x64\Scripts;C:\Tools\perl\5.20.1\x64\bin;C:\Tools\perl\5.20.1\x64\site\bin;D:\coding\lib\qt\4.8.6\x64_mingw-4.9.2_seh\bin;D:\coding\lib\opencv\2.4.10\x64_mingw-4.9.2_seh\bin;C:\Program Files\MiKTeX\miktex\bin\x64;C:\Program Files\Doxygen\bin;C:\Program Files (x86)\Graphviz\bin;C:\Program Files (x86)\Nmap;C:\Program Files (x86)\GPAC

[debug]Command-line: C:\Tools\tdm\4.9.2\x64_seh\bin\gdb.exe -fullname -quiet  -args ./codeblocks.exe
[debug]Working dir : D:\coding\projects\sw\codeblocks\trunk\src\devel_64

Starting debugger: C:\Tools\tdm\4.9.2\x64_seh\bin\gdb.exe -fullname -quiet  -args ./codeblocks.exe
done

[debug]> set prompt >>>>>>cb_gdb:
[debug]Skip initializing the scripting!

Setting breakpoints

[debug]Reading symbols from ./codeblocks.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.8.1
[debug]Copyright (C) 2014 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "x86_64-w64-mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.8.1

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> directory D:/coding/projects/sw/codeblocks/trunk/src/
[debug]Source directories searched: D:/coding/projects/sw/codeblocks/trunk/src;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> set args --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose -p debug
[debug]>>>>>>cb_gdb:
[debug]> source D:\coding\lib\pprinters\wx28.gdb
[debug]>>>>>>cb_gdb:
[debug]> break "D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_driver.cpp:779"
[debug]No source file named D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_driver.cpp.
[debug]Breakpoint 2 ("D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_driver.cpp:779") pending.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: D:\coding\projects\sw\codeblocks\trunk\src\devel_64\codeblocks.exe --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose -p debug

Child process PID: 4820

[debug][New Thread 4820.0x14c4]
[debug][New Thread 4820.0x4e4]
[debug][New Thread 4820.0xf30]
[debug][New Thread 4820.0x794]
[debug][New Thread 4820.0x15f8]
[debug][New Thread 4820.0x1718]
[debug][New Thread 4820.0x1748]
[debug][New Thread 4820.0x156c]
[debug][New Thread 4820.0x2bc]
[debug][New Thread 4820.0x1320]
[debug][Thread 4820.0x1320 exited with code 0]
[debug][New Thread 4820.0x1508]
[debug][Thread 4820.0x1508 exited with code 0]
[debug][New Thread 4820.0x1654]
[debug][Thread 4820.0x1654 exited with code 0]
[debug][New Thread 4820.0x4b8]
[debug][Thread 4820.0x4b8 exited with code 0]
[debug][New Thread 4820.0x13c0]
[debug][Thread 4820.0x13c0 exited with code 0]
[debug][New Thread 4820.0x1120]
[debug][Thread 4820.0x1120 exited with code 0]
[debug][New Thread 4820.0x1158]
[debug][Thread 4820.0x1158 exited with code 0]
[debug][New Thread 4820.0x1500]
[debug][Thread 4820.0x1500 exited with code 0]
[debug][New Thread 4820.0x1698]
[debug][Thread 4820.0x1698 exited with code 0]
[debug][New Thread 4820.0x16d8]
[debug][Thread 4820.0x16d8 exited with code 0]
[debug][New Thread 4820.0x11a0]
[debug][Thread 4820.0x11a0 exited with code 0]
[debug][New Thread 4820.0xcec]
[debug][Thread 4820.0xcec exited with code 0]
[debug][New Thread 4820.0xca8]
[debug][Thread 4820.0xca8 exited with code 0]
[debug][New Thread 4820.0xfdc]
[debug][Thread 4820.0xfdc exited with code 0]
[debug][New Thread 4820.0x110c]
[debug][Thread 4820.0x110c exited with code 0]
[debug][New Thread 4820.0x1150]
[debug][Thread 4820.0x1150 exited with code 0]
[debug][New Thread 4820.0x330]
[debug][Thread 4820.0x330 exited with code 0]
[debug][New Thread 4820.0x17ac]
[debug][Thread 4820.0x17ac exited with code 0]
[debug][New Thread 4820.0xc5c]
[debug][Thread 4820.0xc5c exited with code 0]
[debug][New Thread 4820.0x1528]
[debug][New Thread 4820.0xbc8]
[debug][Thread 4820.0xbc8 exited with code 0]
[debug][New Thread 4820.0x1358]
[debug][New Thread 4820.0x1098]
[debug][Thread 4820.0x1098 exited with code 0]
[debug][New Thread 4820.0x103c]
[debug][Thread 4820.0x103c exited with code 0]
[debug][New Thread 4820.0x1674]
[debug][Thread 4820.0x1674 exited with code 0]
[debug][Thread 4820.0x15f8 exited with code 0]
[debug][New Thread 4820.0x14ec]
[debug]Breakpoint 2, GDB_driver::ParseOutput (this=0x161122d0, output="Reading symbols from D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe...done.") at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779
[debug]D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779:27381:beg:0xafee15b
[debug]>>>>>>cb_gdb:

At D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779

[debug]> info args
[debug]this = 0x161122d0
[debug]output = "Reading symbols from D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe...done."
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  GDB_driver::ParseOutput (this=0x161122d0, output="Reading symbols from D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe...done.") at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779
[debug]#1  0x000000000afdecf2 in DebuggerGDB::ParseOutput (this=0x70a6880, output="Reading symbols from D:/coding/projects/misc/exCpp/bin/Debug/exCpp.exe...done.") at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb.cpp:1691
[debug]#2  0x000000000afdfc91 in DebuggerGDB::OnGDBOutput (this=0x70a6880, event=...) at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb.cpp:1826
[debug]#3  0x0000000062786541 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#4  0x0000000062786603 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#5  0x00000000627869b7 in wxEvtHandler::ProcessEvent(wxEvent&) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#6  0x000000006278645e in wxEvtHandler::ProcessPendingEvents() () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#7  0x00000000627016d9 in wxAppConsole::ProcessPendingEvents() () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#8  0x0000000062b553e0 in wxIdleWakeUpModule::MsgHookProc(int, unsigned long long, long long) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#9  0x00000000770d797c in USER32!GetKeyboardLayoutList () from C:\Windows\system32\user32.dll
[debug]#10 0x00000000770df5fb in USER32!SystemParametersInfoW () from C:\Windows\system32\user32.dll
[debug]#11 0x00000000770e4895 in USER32!IsProcessDPIAware () from C:\Windows\system32\user32.dll
[debug]#12 0x00000000773411f5 in ntdll!KiUserCallbackDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
[debug]#13 0x00000000770eef0a in USER32!GetClipboardData () from C:\Windows\system32\user32.dll
[debug]#14 0x00000000770d5466 in USER32!LockWindowStation () from C:\Windows\system32\user32.dll
[debug]#15 0x00000000055e90f0 in ?? ()
[debug]Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[debug]>>>>>>cb_gdb:

Continuing...

[debug]> cont
[debug]Continuing.
[debug]Breakpoint 2, GDB_driver::ParseOutput (this=0x161122d0, output="(gdb) >>>>>>cb_gdb:") at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779
[debug]> info frame
[debug]D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779:27381:beg:0xafee15b
[debug]>>>>>>cb_gdb:

At D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779

[debug]> info args
[debug]Stack level 0, frame at 0x22f5c0:
[debug] rip = 0xafee15b in GDB_driver::ParseOutput (D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779); saved rip = 0xafdecf2
[debug] called by frame at 0x22f5f0
[debug] source language c++.
[debug] Arglist at 0x22f120, args: this=0x161122d0, output="(gdb) >>>>>>cb_gdb:"
[debug]> bt 30
[debug] Locals at 0x22f120, Previous frame's sp is 0x22f5c0
[debug] Saved registers:
[debug]  rbx at 0x22f598, rsi at 0x22f5a0, rdi at 0x22f5a8, rbp at 0x22f5b0, rip at 0x22f5b8, xmm15 at 0x22f5b8
[debug]>>>>>>cb_gdb:this = 0x161122d0
[debug]output = "(gdb) >>>>>>cb_gdb:"
[debug]>>>>>>cb_gdb:#0  GDB_driver::ParseOutput (this=0x161122d0, output="(gdb) >>>>>>cb_gdb:") at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\gdb_driver.cpp:779
[debug]#1  0x000000000afdecf2 in DebuggerGDB::ParseOutput (this=0x70a6880, output="(gdb) >>>>>>cb_gdb:") at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb.cpp:1691
[debug]#2  0x000000000afdfc91 in DebuggerGDB::OnGDBOutput (this=0x70a6880, event=...) at D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb.cpp:1826
[debug]#3  0x0000000062786541 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#4  0x0000000062786603 in wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#5  0x00000000627869b7 in wxEvtHandler::ProcessEvent(wxEvent&) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#6  0x000000006278645e in wxEvtHandler::ProcessPendingEvents() () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#7  0x00000000627016d9 in wxAppConsole::ProcessPendingEvents() () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#8  0x0000000062b553e0 in wxIdleWakeUpModule::MsgHookProc(int, unsigned long long, long long) () from D:\coding\projects\sw\codeblocks\trunk\src\devel_64\wxmsw28u_gcc_custom.dll
[debug]#9  0x00000000770d797c in USER32!GetKeyboardLayoutList () from C:\Windows\system32\user32.dll
[debug]#10 0x00000000770df5fb in USER32!SystemParametersInfoW () from C:\Windows\system32\user32.dll
[debug]#11 0x00000000770e4895 in USER32!IsProcessDPIAware () from C:\Windows\system32\user32.dll
[debug]#12 0x00000000773411f5 in ntdll!KiUserCallbackDispatcher () from C:\Windows\SYSTEM32\ntdll.dll
[debug]#13 0x00000000770eef0a in USER32!GetClipboardData () from C:\Windows\system32\user32.dll
[debug]#14 0x00000000770d5466 in USER32!LockWindowStation () from C:\Windows\system32\user32.dll
[debug]#15 0x00000000055e90f0 in ?? ()
[debug]Backtrace stopped: previous frame inner to this frame (corrupt stack?)
[debug]>>>>>>cb_gdb:

And I'm still not sure where to check for the faulty code as I didn't get an answer to my question:
Quote from: scarphin on April 01, 2015, 12:10:51 am
Can you please point me to the piece of code where the frame info is parsed, is it 'GDB_driver::ParseOutput'?
Title: Re: Frame issue with the debugger plugin
Post by: ollydbg on April 07, 2015, 01:48:21 am
Quote from: scarphin on April 07, 2015, 01:15:41 am
Yes, many times but I quit after getting errors like:
Code
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
I don't know if it's CB related or something else but I can't deal with it. If you want to see the debug log:
This is definitely an GDB issue. GDB tries to unwind frame through
Code
USER32!LockWindowStation () from C:\Windows\system32\user32.dll
But it failed.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 07, 2015, 03:27:46 am
Quote from: scarphin on April 07, 2015, 01:15:41 am
Yes, many times but I quit after getting errors like:
Code
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Is this error stopping you from debugging? Is this happening in a night build?
As far as I can see the important part of the backtrace is there.

Quote from: scarphin on April 07, 2015, 01:15:41 am
And I'm still not sure where to check for the faulty code as I didn't get an answer to my question:
Quote from: scarphin on April 01, 2015, 12:10:51 am
Can you please point me to the piece of code where the frame info is parsed, is it 'GDB_driver::ParseOutput'?
I've answered this one - just use the debugger to find where the bad value is coming from.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 07, 2015, 05:51:28 pm
Quote from: oBFusCATed on April 07, 2015, 03:27:46 am
Quote from: scarphin on April 07, 2015, 01:15:41 am
Yes, many times but I quit after getting errors like:
Code
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Is this error stopping you from debugging? Is this happening in a night build?
As far as I can see the important part of the backtrace is there.
If you're asking whether this error is stopping or crashing the debugger, no but it disallows me to inspect the variables and for a matter of fact this happens when the output is:
Code
(gdb) >>>>>>cb_gdb:
This error occurs on my self-compiled cb rev10149 both 32-bit and 64-bit. I think I've located the piece of code responsible for parsing the output of 'bt 30' command in 'gdbCmd_Backtrace::ParseOutput' but setting a breakpoint doesn't make the debugger stop there when it's executed. Maybe it's never executed!? Anyway I'm done with tracing that, it's too complicated for me and I'm lost.

Quote from: oBFusCATed on April 07, 2015, 03:27:46 am
I've answered this one - just use the debugger to find where the bad value is coming from.
That is not an answer to my question but a very general advise to use a debugger to debug a bug.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 07, 2015, 09:01:24 pm
Of course it is general, but I have no time to debug it for you and then post backtraces and give suggestions. Also there is a chance that they will be invalid, because I've not debugged cb under windows for quite a long while, only under windows.

Are you using a night build to debug your self build cb?
If you're having problem with a night build then this is probably a bug and should be fixed.

Also if breakpoints are not hit then you can add printfs in order to make sure that the code is executed. I prefer to put deliberate crashing code -> int *a=NULL; *a=5; to verify some code is executed and my breakpoints are failing to hit.

Also if you hit the pause button and the debugger stop correctly, you can inspect the status of your breakpoints with the "info breakpoints" gdb command.
What you're looking in the output is "pending", no breakpoint should be pending, but should have a proper address, source file and line information.
If you have pending in the output you have some problem with the build and/or symbols.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 08, 2015, 12:10:07 am
I checked the latest nightly (rev10158) to see if something's going wrong with my build and not to my surprise the results were the same. Debug log is attached because of the 20000 char limitation.

'info breakpoints' just crushed gdb as you can see at the end of the build log. I tried crashing the debugger on purpose to see whether the code is being executed or not, and it did crash but the breakpoint was never hit without the crashing code inserted.

Btw, I never requested anyone to debug any code for me. I was just trying to trace a bug that occurs on a pure 64-bit cb build which seemed to be a necessity at the time. From what I see developers are quite confident that a 64-bit cb will never see the light of day. So I see no point in chasing that bug any further. Please ignore the whole thread to avoid any further inconvenience.

P.S. I deleted some of the frame responses manually to make the log length reasonable. The missing ones are pretty much the same as the last one.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 08, 2015, 01:12:51 am
Hm, you've added a single breakpoint and the debugger stops at it.
Why are you saying that it fails to do so?

There is some mess after the info frame command. :(
Can you disable the function arguments and locals, so there is less noise in the output.
And also it is a bit safer without evaluating them.

Have you tried to debug cb.exe using command line debugger to verify that the gdb build you're using is working fine?
Also can you execute info breakpoints and bt 30 manually after the debugger stops on the first breakpoint.

p.s. I have nothing against win 64bit build, just I have no intention to work on it, because it is on the wrong OS.
p.p.s. I'm not sure if it is really good idea to pursuit cb 64bit+wx2.8.12. It will probably be easier to target wx3.0 directly.
p.p.p.s. Hm, but at work we are using minimal parts of wx2.6/2.8 in 64bit apps on windows with vc++/icc and there are no major problems.
p.p.p.p.s. My intention is to help, not be rude, sorry if I've offended you.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 08, 2015, 12:40:36 pm
Quote from: oBFusCATed on April 08, 2015, 01:12:51 am
Hm, you've added a single breakpoint and the debugger stops at it.
Why are you saying that it fails to do so?
Because it's the breakpoint:
Code
[debug]> break "D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_commands.h:1207"
[debug]Breakpoint 3 at 0x6daaa2d1: file D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_commands.h, line 1207.
at line 142 of the debug log that it doesn't stop.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 08, 2015, 08:53:39 pm
It has stopped on the breakpoint and then you've hit the continue button. According to the log.
Have you hit the continue button?
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 09, 2015, 01:13:42 am
No, unfortunately.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 09, 2015, 03:47:18 am
There are 2 bugs regarding the original problem.
1- The reason for the invalid frame numbers are the 'ToULongLong' conversions in 'GdbCmd_Backtrace::MatchLine' function in 'gdb_commands.h'. There is a bug report here:
http://trac.wxwidgets.org/ticket/13282 (http://trac.wxwidgets.org/ticket/13282)
2- 'm_number' is defined as 'int' in the 'cbStackFrame' class but it is converted to and from a 'size_t' type in the previously mentioned function. It should be defined as 'ssize_t' if it's required to be a signed type, 'size_t' otherwise. Also 'validFrameNumber' variable in function 'GdbCmd_Backtrace::ParseOutput' should match 'm_number's type.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 09, 2015, 09:05:03 am
Thanks for the digging this up. I'll see what can be done to fix it.

Can you try to build the test project (see in the debuggergdb folder)?
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 09, 2015, 10:52:28 am
Test suite also has the failures for 64-bit:
Code
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:20:1: error: Failure in match0_number: Expected 0 but was 1
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:51:1: error: Failure in match1_number: Expected 8 but was 1
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:58:1: error: Failure in match1_address: Expected 2010416948 but was 5029592
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:90:1: error: Failure in match2_number: Expected 9 but was 8
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:97:1: error: Failure in match2_address: Expected 1770750 but was 2292016
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:128:1: error: Failure in match3_number: Expected 30 but was 135
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:135:1: error: Failure in match3_address: Expected 4209674 but was 5029592
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:166:1: error: Failure in match4_number: Expected 31 but was 1
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:173:1: error: Failure in match4_address: Expected 4224714 but was 5029592
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:204:1: error: Failure in match5_number: Expected 50 but was 0
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:211:1: error: Failure in match5_address: Expected 4263052 but was 3437753
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:246:1: error: Failure in match6_number: Expected 0 but was 2291536
FAILURE: 12 out of 116 tests failed (12 failures).
Test time: 0.10 seconds.

No failures for 32-bit.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 09, 2015, 02:37:49 pm
As an example following approach works for 64-bit:
Code
size_t number, address;
number = strtoull(reBT1.GetMatch(line, 1).mb_str(), nullptr, 10);
address = strtoull(reBT1.GetMatch(line, 2).mb_str(), nullptr, 16);
I think it is also safe considering the regex pattern is ascii (to my understanding).

'strtoull' should be 'strtoll' for signed conversions. Is there a need for 'cbStackFrame::m_number' to be signed?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on April 10, 2015, 01:02:48 am
I don't like the usage of size_t and ssize_t. If you think something should be a particular size then it is better to use int64_t or uint64_t.

About test suite - it is great that it fails, so testing will be a bit easier.
I don't think there is a reason to use 64bit number for the frame, but the address must be 64bit, probably it always has to be 64bit.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on April 10, 2015, 03:29:00 am
Attached patch fixes the 'ToULongLong' problem and the conversion problems between incompatible types. All debugger tests for both 32-bit and 64-bit pass with this patch. 'cdb' part needs testing though.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 27, 2015, 03:50:57 pm
@Morten: Do you have any idea why you've added calls to ToULongLong instead of ToULong for the Windows 64bit builds in revision 9038?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 27, 2015, 03:55:25 pm
@scarphin: I've taken you're patch as a base for this one http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.001.patch can you try it and verify that everything still works?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 28, 2015, 12:55:10 am
This patch http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.002.patch (contains the previous), should fix the disassembly window, too.
Please test and report any problems on both 32 and 64 bit windows.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on September 28, 2015, 01:27:44 am
By disassembly window, do you mean the blank disassembly window?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 28, 2015, 02:04:45 am
Debug -> Debugging windows -> Disassembly

When you stop on a breakpoint it will show the assembler instructions at the current function.
Test stepping in and out of functions, going to the next instruction, etc.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on September 28, 2015, 03:31:22 am
I meant the blank disassembly window bug but anyway it's not that it seems.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 28, 2015, 08:29:35 am
No idea what bug you're talking about.
Do you have a link with description?
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on September 28, 2015, 12:33:43 pm
It occurs with embedded compilers (i.e. avr-gcc), it might be a gdb configuration problem or an actual bug. Currently I don't have a setup to produce it, I'll provide more information when I can if I can.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on September 28, 2015, 01:45:55 pm
Quote from: oBFusCATed on September 28, 2015, 12:55:10 am
This patch http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.002.patch (contains the previous), should fix the disassembly window, too.
Please test and report any problems on both 32 and 64 bit windows.
Fails to compile with:
Code
D:\coding\projects\sw\codeblocks\trunk\src\sdk\debuggermanager.cpp: In function 'wxString cbDebuggerAddressToString(uint64_t)':
D:\coding\projects\sw\codeblocks\trunk\src\sdk\debuggermanager.cpp:499:18: error: could not convert 'std::basic_stringstream<_CharT, _Traits, _Alloc>::str() const [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::basic_stringstream<_CharT, _Traits, _Alloc>::__string_type = std::basic_string<char>]()' from 'std::basic_stringstream<char>::__string_type {aka std::basic_string<char>}' to 'wxString'
     return s.str();
                  ^

mingw-builds compiler 4.9.2.rev3
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 28, 2015, 08:11:40 pm
Try using something like this: return wxString(s.str().c_str(), wxConvUTF8);
It seems, I've not tested the latest revision with wx2.8.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on September 28, 2015, 08:44:31 pm
Quote from: oBFusCATed on September 28, 2015, 08:11:40 pm
It seems, I've not tested the latest revision with wx2.8.
Please make sure it compiles first then I'll test it. Currently I don't have much time to try to make a patch I'm not familiar with compile.

Btw the patch doesn't apply with svn, I had to use git to apply it. Others also willing to test this might complain about that if you don't fix it.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on September 28, 2015, 09:29:01 pm
Quote from: scarphin on September 28, 2015, 08:44:31 pm
Please make sure it compiles first then I'll test it. Currently I don't have much time to try to make a patch I'm not familiar with compile.
Fine. Just keep in mind that I can't test this on windows (not enough time), and especially I have no intention to test it on win 64bit.
So I suppose you'll have to make changes if something fails.

Quote from: scarphin on September 28, 2015, 08:44:31 pm
Btw the patch doesn't apply with svn, I had to use git to apply it. Others also willing to test this might complain about that if you don't fix it.
What do you mean by this? As far as I know svn doesn't have a command to apply patches.
So the problem is in your patch utility. If you're using tortoisesvn to apply it then try with command line based patch or complain to the devs of tortoise svn.

Also if you open the patch you'll see that this is not a git patch. I've preprocessed it, but I guess this is not enough and I should stop bothering with it this because it doesn't work whatever I do on windows...  :o
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 04, 2015, 03:01:17 am
Updated patches:
http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.2.001.patch
http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.2.002.patch

On linux they build with both wx2.8 and wx3.x.
Title: Re: Frame issue with the debugger plugin
Post by: MortenMacFly on October 04, 2015, 09:24:41 am
Quote from: oBFusCATed on October 04, 2015, 03:01:17 am
Updated patches:
http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.2.001.patch
http://cmpt.benbmp.org/codeblocks/patches/dbg.win64.support.2.002.patch
Sorry, but those patches do not apply on SVN trunk.

Can you apply Jens' cleanup script to they are compatible? Otherwise testing will be hard...
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on October 04, 2015, 09:58:02 am
I attached svn compatible (whatever) versions. I think the problem is with the lines:
Code
@@ -123,7 +124,7 @@ class DLLIMPORT cbStackFrame
where the svn (whatever) generated version is like:
Code
@@ -123,7 +124,7 @@
This seems to be some kind of a setting problem and is NOT related to my patching utility.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 04, 2015, 11:14:40 am
Quote from: MortenMacFly on October 04, 2015, 09:24:41 am
Can you apply Jens' cleanup script to they are compatible? Otherwise testing will be hard...
If you give me a link to it, I can start using it. Otherwise I'll just give you links to a branch on github next time.
Title: Re: Frame issue with the debugger plugin
Post by: MortenMacFly on October 04, 2015, 04:41:31 pm
Quote from: oBFusCATed on October 04, 2015, 11:14:40 am
If you give me a link to it, I can start using it. Otherwise I'll just give you links to a branch on github next time.
Its somewhere in the forums or at Jens' homepage? I don't recall as I don't use it. I thought you would remember as we had that topic the one or other time already.

But nevermind - the new patches work fine. I guess I have to apply only one, so I took the second and will try what happens (although debugging wxWidgets apps using C::B is currently heavily broken with recent TDM release).

Do you have a particular test case to try on Windows? Or should I just debug "anything"?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 04, 2015, 05:11:20 pm
"Debug anything" should probably be enough.  8)
Title: Re: Frame issue with the debugger plugin
Post by: MortenMacFly on October 04, 2015, 08:03:44 pm
Quote from: scarphin on October 04, 2015, 09:58:02 am
I attached svn compatible (whatever) versions. I think the problem is with the lines:
Code
@@ -123,7 +124,7 @@ class DLLIMPORT cbStackFrame
where the svn (whatever) generated version is like:
Code
@@ -123,7 +124,7 @@
This seems to be some kind of a setting problem and is NOT related to my patching utility.
This was one issue and the second one (more bad) was that the line(s) like:
+++ src/include/cbdebugger_interfaces.h    (working copy)
...contained tabulator(s) after the file name which is invalid and makes SVN look for a file named "src/include/cbdebugger_interfaces.h    (working copy)" which obviously does not exist.

BTW: I am using "svn patch foo.patch" on the command line (svn version 1.9.1). So it maybe a SVN issue after all...
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 04, 2015, 08:14:49 pm
Quote from: MortenMacFly on October 04, 2015, 08:03:44 pm
BTW: I am using "svn patch foo.patch" on the command line (svn version 1.9.1). So it maybe a SVN issue after all...
Interesting,  so there is a patch command in svn.
Can you contact svn support to see what they have to say about this problem?
Last time I've tried to apply patches generated by my script using the standalone patch tool on linux it worked without errors.
Title: Re: Frame issue with the debugger plugin
Post by: MortenMacFly on October 06, 2015, 03:16:23 pm
Quote from: oBFusCATed on October 04, 2015, 08:14:49 pm
Can you contact svn support to see what they have to say about this problem?
I got an answer:
The error is on your side: In the original patch there were spaces between the file name and the revision. There should have been a tab as you cannot differ between a file name that ends with a space (which is possible, indeed) and a separator.

So, this is wrong:
+++ src/include/cbdebugger_interfaces.h[1..n space](working copy)
...this is right:
+++ src/include/cbdebugger_interfaces.h[1..n TAB](working copy)
And indeed: With that minor modification the original patch applied safely.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 06, 2015, 07:14:44 pm
What? Are you joking? They are failing to apply this patch because of some strange convention they've made up?
The good thing is that svn has only one direction it will follow - to join cvs in the vcs oblivion land.  ;D Hopefully this will happen in the not so distant future.

Anyway I'll look in the script and I'll try to fix it.

Edit:
Code
Index: src/CodeBlocks_wx30-unix.cbp
===================================================================
--- src/CodeBlocks_wx30-unix.cbp    	(revision 10528)
+++ src/CodeBlocks_wx30-unix.cbp    	(working copy)
@@ -149,7 +149,7 @@
 				<Option output="devel30/codeblocks" prefix_auto="1" extension_auto="1" />
 				<Option working_dir="devel30" />
 				<Option object_output=".objs30" />
-				<Option type="0" />
+				<Option type="1" />
 				<Option compiler="gcc" />
 				<Option parameters="--debug-log --multiple-instance -ns -ni -v -p debug" />
 				<Option projectLinkerOptionsRelation="2" />
@@ -507,7 +507,7 @@
 			</Target>
 			<Environment>
 				<Variable name="WX_CFG" value="" />
-				<Variable name="WX_CONFIG" value="wx-config --version=3.0" />
+				<Variable name="WX_CONFIG" value="/home/obfuscated/software/wx/bin/wx-config" />
 				<Variable name="WX_SUFFIX" value="u" />
 				<Variable name="WX_VERSION" value="30" />
 			</Environment>
@@ -519,7 +519,7 @@
 		</VirtualTargets>
 		<Compiler>
 			<Add option="-Wall" />
-			<Add option="-ansi" />
+			<Add option="-std=c++11" />
 			<Add option="$(#CB_RELEASE_TYPE)" />
 			<Add option="-fmessage-length=0" />
 			<Add option="-fexceptions" />

Does this apply out of the box?
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 17, 2015, 10:22:56 am
Any status update? Is this patch working on your side? Should I commit it?
Title: Re: Frame issue with the debugger plugin
Post by: MortenMacFly on October 17, 2015, 12:32:44 pm
Quote from: oBFusCATed on October 17, 2015, 10:22:56 am
Any status update? Is this patch working on your side? Should I commit it?
So here is what I tried:
- C::B wx28 + wx30/32 bit + wx30/64 bit build (3 in total)
- "Tester App" with some function calls and calculations
- compiled this using MinGW and MinwGW64 (TDM 5.1)
- Debugged with gdb32/gdb64 respectively (TDM 5.1)

No strange observations.

For me its fine, although I didn't realise there was an issue at all w/o the patch.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on October 17, 2015, 01:11:38 pm
The original issue is limited to wx2.8 + 64bit. You can see screenshots in the very 1st post.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 17, 2015, 03:01:35 pm
Scarphin have you tried the patches with your build configuration?
Title: Re: Frame issue with the debugger plugin
Post by: MortenMacFly on October 17, 2015, 04:57:20 pm
Quote from: scarphin on October 17, 2015, 01:11:38 pm
The original issue is limited to wx2.8 + 64bit. You can see screenshots in the very 1st post.
Do you mean its w28 related, or 64 bit related? From the changes you did I would guess that this should happen on any 64 bit build - be it wx28 or wx30.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 17, 2015, 09:39:08 pm
The original issue (user visible) is that some of the string to number conversion functions in wx are wrong.

The patches try to fix the more serious problem - debugging a 64bit program with 32bit codeblocks.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on October 17, 2015, 11:39:48 pm
Morten: It's related to the mix of wx28 and 64-bit. The actual problem arises from a conversion function in wx28 not functioning properly when built under a 64-bit configuration. It's a known wx problem, you can find a link to the wx tracker somewhere on this thread. If I recall correctly, later wx versions (I think starting from wx29) doesn't exhibit this problem.

Obfuscated: I'm very busy nowadays, I'll test it in a couple of days hopefully.
Title: Re: Frame issue with the debugger plugin
Post by: scarphin on October 19, 2015, 11:56:11 pm
The 2nd patch (dbg.win64.support.2.002.patch) works fine displaying both the frame number and assembler addresses correctly on my wx2.8 64-bit build. If it matters, I even tested it on a 64-bit application.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 19, 2015, 11:58:50 pm
Thanks. Using the patch it should always be possible to debug both 32 and 64bit apps.
I'll commit in a minute.
Title: 32-bit build on linux broken
Post by: Jenna on October 23, 2015, 08:47:09 pm
It seems that commit 10539 together with 10540 break 32-bit build on linux.
See this error log-snippet:
Code
debuggermanager.cpp: In function 'uint64_t cbDebuggerStringToAddress(const wxString&)':
debuggermanager.cpp:488:36: error: no matching function for call to 'wxString::ToULong(uint64_t*, int) const'
     if (address.ToULong(&result, 16))
                                    ^
In file included from /usr/include/wx-2.8/wx/artprov.h:15:0,
                 from debuggermanager.cpp:12:
/usr/include/wx-2.8/wx/string.h:1188:10: note: candidate: bool wxString::ToULong(long unsigned int*, int) const
     bool ToULong(unsigned long *val, int base = 10) const;
          ^
/usr/include/wx-2.8/wx/string.h:1188:10: note:   no known conversion for argument 1 from 'uint64_t* {aka long long unsigned int*}' to 'long unsigned int*'
The cause is the use of this newly added function:

Code: diff
@@ -459,6 +472,30 @@ wxString cbDetectDebuggerExecutable(const wxString &exeName)
     return exePath + wxFileName::GetPathSeparator() + exeName + exeExt;
 }
 
+uint64_t cbDebuggerStringToAddress(const wxString &address)
+{
+    if (address.empty())
+        return 0;
+#if defined(__WXMSW__)
+    // Workaround for the 'ToULongLong' bug in wxWidgets 2.8.12
+#if wxCHECK_VERSION(2, 8, 12)
+    return strtoull(address.mb_str(), nullptr, 16);
+#else
+    uint64_t result;
+    if (address.ToULongLong(&result))
+        return result;
+    else
+        return 0;
+#endif // wxCHECK_VERSION
+#else
+    uint64_t result;
+    if (address.ToULong(&result, 16))
+        return result;
+    else
+        return 0;
+#endif
+}
+
 
 class DebugTextCtrlLogger : public TextCtrlLogger
 {

(1) Is there any reason for the #if defined(__WXMSW__) ?
(2) And if yes, shouldn't it be address.ToUlongLong in the else-clause ?

Or in other words, is the ToUlongLong-bug (which ?) a windows-only (2) bug or is it a bug on all systems (1) ?
Title: Re: 32-bit build on linux broken
Post by: oBFusCATed on October 23, 2015, 09:08:24 pm
Quote from: jens on October 23, 2015, 08:47:09 pm
(1) Is there any reason for the #if defined(__WXMSW__) ?
(2) And if yes, shouldn't it be address.ToUlongLong in the else-clause ?

Or in other words, is the ToUlongLong-bug (which ?) a windows-only (2) bug or is it a bug on all systems (1) ?

This is the original topic http://forums.codeblocks.org/index.php/topic,20155.0.html
I think you can find the bug report about toulonglong there.
Probably I've messed it a bit here.
We should always use ToULongLong on windows, because sizeof(long)==4 there.
See this table https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models

Probably we should use ToULongLong on 32bit linux/osx. Can you detect this case?

Also can you move these two posts in the original topic?

Title: Re: 32-bit build on linux broken
Post by: Jenna on October 23, 2015, 11:04:19 pm
Quote from: oBFusCATed on October 23, 2015, 09:08:24 pm
Also can you move these two posts in the original topic?
Done.

Quote from: oBFusCATed on October 23, 2015, 09:08:24 pm
Probably we should use ToULongLong on 32bit linux/osx. Can you detect this case?
I think this should work.
I can test the build on my copr-site, but not whether it works or not (at the moment).
I'm not at home until sunday, so I can not set up a 32bit test-machine (too slow internet) and I will only be at home for some hours sunday evening.
Title: Re: Frame issue with the debugger plugin
Post by: Jenna on October 23, 2015, 11:12:00 pm
Another thing I just stumbled about:
all calls of string2ulong[long] in the cbDebuggerStringToAddress-function have a base of 16, except the ToULongLong-call for wx > 2.8.12 on windows.
Title: Re: Frame issue with the debugger plugin
Post by: oBFusCATed on October 24, 2015, 12:06:24 am
This last thing is a bug, if you're committing please fix it.
Title: Re: Frame issue with the debugger plugin
Post by: Jenna on October 24, 2015, 01:07:23 am
In trunk.
I need to distinguish between 64bit and 32bit, because of the different size of long/long long.
It builds now, but is not tested on 32bit linux and not tested at all on Mac.