Author Topic: The 17 September 2011 build (7452) DEBUGGER BRANCH version is out. (Read 76545 times)

killerbot · « **on:** September 17, 2011, 03:53:50 pm »

Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc452-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc452-TDM.7z

The 17 September 2011 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20110917_rev7452_DEBUGGER_BRANCH_win32.7z
  - Linux :
   none

Important changes compared to previous DEBUGGER BRANCH nightly:

* debugger_branch:
better calculate the horizontal size of the tooltips (widen/shrink when sub properties are expanded/collapsed);
fit the columns, so all the text is visible (if possible);
* debugger_branch: Add parentheses around the symbol, when executing the output command in the watch and the current watch is an array with start index and count.
This way we prevent the execution of the custom operator[] (if defined), when the watch symbol is something like - (float*)&mystruct.
* debugger_branch: allow a scintilla dwell start to be sent on windows, when the ctrl key is pressed (changes the wxscintilla code);
* debugger_branch: disable the Rename/Properties/Delete menu item, when the user shows the context menu for a child watch; (has an API change)
* debugger_branch:
* fixed the calculation of the widths of the wxPropGrid columns for the ValueTooltip (used the non-clamped width);
* made the min width/height to be dependent on the width/height of the screen;
* debugger_branch: add function to the SDK for detecting the path to the debugger (mostly gdb)
* all updates that occurred on trunk

Note: Watch parsing prints an error message in the watches window if the parsing fails. If you see this string please report it as a bug.

THIS IS A SPECIAL TEST BUILD OF REFACTORINGS CARRIED OUT ON THE DEBUGGER BRANCH IN OUR SVN.
FOCUS IS ON ENHANCED DEBUGGING USABILITY.

Give your feedback on this version only in this thread, don't mix it with the regular nightly please. If you feel it is however not
related to the debugger functionality itself, then it might be better to report it the corresponding regular nightly build thread.

Once we don't have any blockers on this version,we will merge the changes into trunk and it will be part of the regular nightlies.

Jenna · « **Reply #1 on:** September 17, 2011, 08:22:48 pm »

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

If you want to use apt (or dselect, synaptic or whatever) you need to add the following entries to /etc/apt/sources.list :

Code

deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg

and remove entries for the normal nightlies.

Alternatively you can download the deb's directly from http://apt.jenslody.de/pool/dbg/c/codeblocks/ .

scarphin · « **Reply #2 on:** September 18, 2011, 06:23:02 pm »

I'm experiencing a crash.
1-Launch cb.
2-Plugins->manage plugins and choose spellchecker plugin.
3-Disable, enable, disable crashes cb.

OS: Win7 SP1

oBFusCATed · « **Reply #3 on:** September 18, 2011, 07:14:59 pm »

Not a debugger's problem, reread the first post please and report the crash in the correct topic.

scarphin · « **Reply #4 on:** September 18, 2011, 07:41:47 pm »

I didn't say it's a debugger problem but it says:

Quote

Give your feedback on this version only in this thread, don't mix it with the regular nightly please.

I'm not using the regular nightly but this branch so where should I report this?

oBFusCATed · « **Reply #5 on:** September 18, 2011, 07:46:33 pm »

Killerbot: can you change the text above to: "Please report only bugs related to the debugger, if you find a non debugger bug please test with the normal nightly and report the problem in the appropriate topic" or something like that.

killerbot · « **Reply #6 on:** September 18, 2011, 08:35:13 pm »

Freem · « **Reply #7 on:** September 18, 2011, 09:56:48 pm »

I don't see the difference about the "min size dependent on width/height of the screen".
Did you spoke about the size of panel?
With my eeePC it is still impossible to resize them to have more than 23 lines if I place the watch panel horizontally. (98 characters for width, but it's enough)

It seem the debug tip have been correctly fixed, thanks a lot.

I didn't tried yet other enhancements, but really, thanks for all the work.

oBFusCATed · « **Reply #8 on:** September 19, 2011, 12:01:50 am »

What min size? If you're looking at the svn log, this is only for tooltips.

chao · « **Reply #9 on:** September 27, 2011, 03:24:55 am »

Hi, thanks for the work,
I just tried the debugger branch, and I like the new watch window.

It can display elements within a vector, which is great.

But It does not show such information for deque or list,
is that a bug, or is there a plan to support more containers?

oBFusCATed · « **Reply #10 on:** September 27, 2011, 08:20:24 am »

Install python pretty printers, enable them, disable the internal ones and you'll have deque support.
For more info search the forum.

chao · « **Reply #11 on:** September 27, 2011, 11:05:06 am »

Quote from: oBFusCATed on September 27, 2011, 08:20:24 am

Install python pretty printers, enable them, disable the internal ones and you'll have deque support.
For more info search the forum.

Thank you very much. I didn't know that.
I just installed the scripts, I found 'gdb-python27.exe' in my mingw\bin dir and used it, and it worked

.

Sometimes the 2nd item of a deque is displayed in the first row, while the 1st item in 2nd row; vector and list are fine.

oBFusCATed · « **Reply #12 on:** September 27, 2011, 01:05:40 pm »

Quote from: chao on September 27, 2011, 11:05:06 am

Sometimes the 2nd item of a deque is displayed in the first row, while the 1st item in 2nd row; vector and list are fine.

Probably there are parser problems, I've no time at the moment to dig deep into the pretty printers...

chao · « **Reply #13 on:** September 28, 2011, 03:03:49 am »

Quote from: oBFusCATed on September 27, 2011, 01:05:40 pm

Probably there are parser problems, I've no time at the moment to dig deep into the pretty printers...

Thanks anyway. And that's not much of a problem.

oBFusCATed · « **Reply #14 on:** October 05, 2011, 09:33:24 am »

Why are you posting this again and in the wrong topic?
This is only for debugger problems, the normal non-debugger related
problems should be reported in the trunk nightly topic.

Sorry if I'm being rude.

imianz · « **Reply #15 on:** October 05, 2011, 11:10:25 am »

I'm sorry, it's a my mistake, I move it to the right section (I hope!)

renega_666 · « **Reply #16 on:** October 05, 2011, 01:23:23 pm »

Hi!

I have an issue with breakpoints and the call stack window in the debugger branch (rev 7452) on Windows XP and Windows 7.

1)Whenever I remove a break point while my program is running, this break point is always hit. It disappears if I stop debugging and restart again.

2) The call stack is always empty when my program hit a break point. I have to close the call stack window and re-open it to view its content.

I'm only using the debugger branch so I don't know if those bugs are only related to this branch.

oBFusCATed · « **Reply #17 on:** October 05, 2011, 01:34:59 pm »

Can I ask you to enable the full debugger's log (Settings -> Debugger -> Debugger's debug log) and then paste it here (using code tags)?

renega_666 · « **Reply #18 on:** October 05, 2011, 01:50:00 pm »

Of course, here it is:

Code

PATH=.;D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\bin\Debug;D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\bin\Release;D:\Projects\TestGameEngine\libs\SirmoGameEngine\libs\Sirmo3DEngine\trunk\bin\Debug;D:\Projects\TestGameEngine\libs\SirmoGameEngine\libs\Sirmo3DEngine\trunk\bin\Release;D:\Projects\TestGameEngine\libs\SirmoGameEngine\libs\SirmoSoundEngine\trunk\bin\Debug;D:\Projects\TestGameEngine\libs\SirmoGameEngine\libs\SirmoSoundEngine\trunk\bin\Release;D:\Projects\TestGameEngine\libs\SirmoGameEngine\libs\libsig\lib;D:\Projects\TestGameEngine\libs\SirmoGameEngine\libs\sfml\lib;C:\MinGW32\bin;C:\Program Files\NVIDIA Corporation\PhysX\Common;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;C:\Program Files\doxygen\bin;C:\Program Files\Fichiers communs\Autodesk Shared\;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\DoxyGen1_6\bin;C:\Program Files\Fichiers communs\Adobe\AGL;C:\Program Files\Graphic Remedy\gDEBugger\;C:\Program Files\Autodesk\Backburner\;C:\Program Files\Visual Leak Detector\bin;C:\Program Files\NVIDIA Corporation\Cg\bin;C:\Program Files\Lua\5.1;C:\Program Files\Lua\5.1\clibs;C:\Program Files\AMD\CodeAnalyst\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\Cppcheck\;C:\Program Files\Graphviz 2.28\bin;C:\Program Files\Internet Explorer;C:\Program Files\NVIDIA Corporation\Cg\bin;C:\Program Files\IDM Computer Solutions\UltraCompare\;C:\Program Files\COLLADA\COLLADA_Refinery\bin;C:\Program Files\Java\jre6\bin
Command-line: C:\MinGW32\bin\gdb.exe -nx -fullname  -quiet -args D:/Projects/TestGameEngine/trunk/bin/Debug/TestGameEngine_d.exe
Working dir : D:\WorkingDirectory
> set prompt >>>>>>cb_gdb:
Reading symbols from d:\projects\testgameengine\trunk\bin\debug\TestGameEngine_d.exe...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.3
Copyright (C) 2011 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 print elements -1
>>>>>>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:
> set print static-members off
show print static-members off

>>>>>>cb_gdb:Printing of C++ static members is off.
> directory D:/Projects/TestGameEngine/trunk/
>>>>>>cb_gdb:Printing of C++ static members is off.
> break "D:/Projects/TestGameEngine/trunk/src/TestApplication.cpp:105"
>>>>>>cb_gdb:
> run
>>>>>>cb_gdb:Breakpoint 2 at 0x403b5c: file D:\Projects\TestGameEngine\trunk\src\TestApplication.cpp, line 105.
>>>>>>cb_gdb:
gdb: windows_init_thread_list
[New Thread 3408.0x698]
[New Thread 3408.0x718]
[New Thread 3408.0xc38]
[New Thread 3408.0x8e0]
[New Thread 3408.0x6ec]
[New Thread 3408.0x504]
[New Thread 3408.0xc50]
[New Thread 3408.0xb88]
[New Thread 3408.0xac4]
[New Thread 3408.0x780]
warning: !!!Warning!!!: Impossible de jouer l'animation du modèle, l'index est out of range!
Breakpoint 2, sge::TestApplication::onFramePreUpdate (this=0x23fdb8) at D:\Projects\TestGameEngine\trunk\src\TestApplication.cpp:105
d:\projects\testgameengine\trunk\src\testapplication.cpp:105:3701:beg:0x403b5c
>>>>>>cb_gdb:
> set debugevents off
> bt 30
>>>>>>cb_gdb:
#0  sge::TestApplication::onFramePreUpdate (this=0x23fdb8) at D:\Projects\TestGameEngine\trunk\src\TestApplication.cpp:105
#1  0x6cb4bad6 in sge::GameApplication::doFrame (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:330
#2  0x6cb4ba2a in sge::GameApplication::doGameLoop (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:317
#3  0x6cb4aac7 in sge::GameApplication::Run (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:132
Cannot access memory at address 0x0
#4  0x004016ef in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f20 "", nCmdShow=10) at D:\Projects\TestGameEngine\trunk\main.cpp:32
#5  0x0041954e in main (argc=) at ../mingw/main.c:73
>>>>>>cb_gdb:
> bt 30
Cannot access memory at address 0x0
#0  sge::TestApplication::onFramePreUpdate (this=0x23fdb8) at D:\Projects\TestGameEngine\trunk\src\TestApplication.cpp:105
#1  0x6cb4bad6 in sge::GameApplication::doFrame (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:330
#2  0x6cb4ba2a in sge::GameApplication::doGameLoop (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:317
#3  0x6cb4aac7 in sge::GameApplication::Run (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:132
#4  0x004016ef in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f20 "", nCmdShow=10) at D:\Projects\TestGameEngine\trunk\main.cpp:32
#5  0x0041954e in main (argc=) at ../mingw/main.c:73
>>>>>>cb_gdb:
> cont
Breakpoint 2, sge::TestApplication::onFramePreUpdate (this=0x23fdb8) at D:\Projects\TestGameEngine\trunk\src\TestApplication.cpp:105
d:\projects\testgameengine\trunk\src\testapplication.cpp:105:3701:beg:0x403b5c
>>>>>>cb_gdb:
> bt 30
Cannot access memory at address 0x0
#0  sge::TestApplication::onFramePreUpdate (this=0x23fdb8) at D:\Projects\TestGameEngine\trunk\src\TestApplication.cpp:105
#1  0x6cb4bad6 in sge::GameApplication::doFrame (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:330
#2  0x6cb4ba2a in sge::GameApplication::doGameLoop (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:317
#3  0x6cb4aac7 in sge::GameApplication::Run (this=0x23fdb8) at D:\Projects\TestGameEngine\libs\SirmoGameEngine\trunk\src\GameApplication.cpp:132
#4  0x004016ef in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f20 "", nCmdShow=10) at D:\Projects\TestGameEngine\trunk\main.cpp:32
#5  0x0041954e in main (argc=) at ../mingw/main.c:73
>>>>>>cb_gdb:
> quit

Hope this will help you!

oBFusCATed · « **Reply #19 on:** October 05, 2011, 02:21:20 pm »

Code

Cannot access memory at address 0x0

Probably this breaks the call stack refresh.

p.s. I've added it to the TODO list and I'll check it when I get there.
p.p.s. At the moment I've redesigned the breakpoints, so this should wait a bit, I'm just testing it now.

renega_666 · « **Reply #20 on:** October 05, 2011, 02:27:43 pm »

Ok take your time!
this is just a little issue that doesn't prevent me from working

Aradayn · « **Reply #21 on:** October 07, 2011, 11:15:02 pm »

First, thank you to everyone who's made Code::Blocks possible. The debugger branch has improved an already great project; thanks!

I'd like to report two related debugging problems.

First, when I try debugging, I get the message:
"ERROR: You need to specify a debugger program in the debuggers's settings."

In an attempt to fix this problem, I went to the menu, but the build crashed when I went to the Settings > Debugger... menu option.

codeblocks.exe caused an Unknown [0xC000041D] Exception at location 734d4c4f.

Registers:
eax=0cf46500 ebx=00000001 ecx=00000000 edx=00000000 esi=0000a918 edi=0004175c
eip=763a40c4 esp=00093f3c ebp=00093f88 iopl=0 nv up ei pl zr na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246

Call stack:
763A40C4 USER32.dll:763A40C4 GetScrollInfo
763A410F USER32.dll:763A410F SetScrollInfo
763BD55F USER32.dll:763BD55F SetScrollRange
7213E05E COMCTL32.DLL:7213E05E Ordinal382
720BD0E6 COMCTL32.DLL:720BD0E6 GetWindowSubclass
7213D744 COMCTL32.DLL:7213D744 ImageList_Draw
720BD0E6 COMCTL32.DLL:720BD0E6 GetWindowSubclass
7213D744 COMCTL32.DLL:7213D744 ImageList_Draw
720BD0E6 COMCTL32.DLL:720BD0E6 GetWindowSubclass
7213D744 COMCTL32.DLL:7213D744 ImageList_Draw

The function calls continue on like that. I updated the wxwidgets DLL and also tried running the program in administrator mode, but neither seemed to help. I'm running on Windows 7 service pack 1.

oBFusCATed · « **Reply #22 on:** October 07, 2011, 11:34:06 pm »

Yes, another one who has this mysterious crash.
So now if we could understand why it is happening...

I've tried to debug it, but I couldn't understand the reason.

Edit: do you happen to have tortoise svn 64bit installed or other shell extensions?

Aradayn · « **Reply #23 on:** October 07, 2011, 11:51:35 pm »

Maybe it has something to do with the version of MinGW/GDB I'm using?

gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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/>.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/development/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --wi
th-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-r
untime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)

Edit: Yes, I have Tortoise SVN 64 installed as a shell extension. I also have the AMD VISION Engine Control Center extension (ATI graphics card stuff)

oBFusCATed · « **Reply #24 on:** October 08, 2011, 12:31:19 am »

The GDB is not involved in the crash.
The crash happens somewhere in the user32.dll, gdi32.dll or some other system dll.
Can you try to remove/uninstall the TortoiseSVN? I'm not on windows at the moment and I can't test it right now.

p.s. I'm using nVidia card. I guess it is not a bad video driver.
p.p.s. Unfortunately I can debug it with gdb, because it doesn't understand ms symbols. :?

Aradayn · « **Reply #25 on:** October 08, 2011, 06:53:51 am »

I uninstalled Tortoise SVN, restarted, and am still getting the same crash.

oBFusCATed · « **Reply #26 on:** October 08, 2011, 08:42:26 am »

OK, What else do you have installed?
If you don't want to state it in public send me an Personal message.

ollydbg · « **Reply #27 on:** October 08, 2011, 09:07:48 am »

Quote from: Aradayn on October 07, 2011, 11:15:02 pm

crashed when I went to the Settings > Debugger... menu option.

I have no such crash.
I guess there are something when when c::b try to open the Debugger dialog and read the associated resources. Maybe, your configure file is wrong, can you try to remove/backup all the c::b configurations, and use/create a new one for testing?

oBFusCATed · « **Reply #28 on:** October 08, 2011, 07:00:24 pm »

ollydbg: There is not resource file involved in this dialog. The dialog is created with wxSmith, so it is all code. And the strangest thing is that it fails somewhere deep in the Win32/64 apis

. And it fails on only two computers: mine and Aradayn's one. I've tried it on 3-4-5 other installs and it worked perfectly.

Aradayn · « **Reply #29 on:** October 08, 2011, 09:22:58 pm »

I deleted everything in my Code Blocks as well as AppData/CodeBlocks, created a new folder from the nightly build and copied the wxwidgets DLL to it, and the crash still occurred on selecting the Settings > Debugging... menu item.

As far as installed programs... Well, I have lots. Too many to list. As far as ones with shell extensions, I had 7-Zip and Tortoise SVN and VLC, and I uninstalled all of these and it still crashed. I also had this extension that calculated the hashes of files in the properties dialog, and I uninstalled that one, too, but it still crashes. I still have the Microsoft Security Essentials extension and the DirectX SDK texture conversion extension too.

ollydbg · « **Reply #30 on:** October 09, 2011, 09:54:36 am »

@obf, I found a tiny bug.

When I try to run a gdb command in the command edit control which is in the bottom of the debugger/debugger log panel. I found that some times, I will lose the focus, but some times I still get the focus in the edit control.

Here is a test program:

Code

int main()
{
    int a = 0;
    a++;
    a=3;
    ;
}

The, I set a breakpoint in the line 3.

CASE one (good case) :
I just run the command "p a", then gdb will show its value, this way, I still get the focus, so I can still press the keyboard, and enter other command again.

CASE two (bad case):
Enter the command "p b". Note, b is not defined in the context, so gdb will complain:

Code

> p a
$6 = 1
> p b
No symbol "b" in current context.

But after that, I loss my edit focus.

I just test under WinXP. Can someone reproduce this bug?

oBFusCATed · « **Reply #31 on:** October 09, 2011, 12:52:50 pm »

ollydbg: Can reproduce on linux.

MortenMacFly · « **Reply #32 on:** October 23, 2011, 08:12:19 pm »

C::B debugger's branch, latest revision, Windows 7 / 64 bit, TDM GCC 64 bit compiler suite.

When I compile a simple wxWidgets based "Hello World" app (wxWidgets 2.9.2, compiled for 64 bit) whenever I start the debugger, C::B stalls. The stop / pause button does not work, the debugger it becomes in-responsible until I kill the gdb process.

The reason seems the following:
In the debugger's debug log I see:
Command-line: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname -quiet -args C:/Code/CodeBlocks_Projects/HelloWorld/HelloWorld_64.exe Working dir : C:\Code\CodeBlocks_Projects\HelloWorld > set prompt >>>>>>cb_gdb: "c:\code\codeblocks_projects\helloworld\HelloWorld_64.exe": not in executable format: File format not recognized (gdb) >>>>>>cb_gdb:
...later on:
> run No executable specified, use `target exec'.

It seems GDB is waiting for an input here. :-(

I know (meanwhile) that TDM's 64 bit compiler suite ships with a debugger not valid for 64 bit, however, the freeze shouldn't happen. Did somebody else experience the same?

Jenna · « **Reply #33 on:** October 23, 2011, 11:01:55 pm »

I get a similar issue on linux, if the executable does not exist and "autobuold to ensure project is up to date" (or how it is called exactly) is unchecked.
gdb hangs and can not be stopped with pause- or stop-button:

Code

> run
No executable file specified.
Use the "file" or "exec-file" command.
>>>>>>cb_gdb:
Code::Blocks is trying to interrupt process with pid: 23917; child pid: 0 gdb pid: 23917
Quit
>>>>>>cb_gdb:
Code::Blocks is trying to interrupt process with pid: 23917; child pid: 0 gdb pid: 23917
Quit
>>>>>>cb_gdb:

First try was pause, second was stop.

In trunk stopping gdb works.

23917 is the pid of gdb and killing it from commandline with default signal (TERM [15]) works.

oBFusCATed · « **Reply #34 on:** October 23, 2011, 11:32:15 pm »

As I've said to Morten on PM, I'll look in to the problem (not sure when, because I have some other things to do at the moment).
Stopping doesn't work, because C::B is sending SIGINT to the child of gdb, not to gdb directly.
I'll look in to this, too, it is on the TODO, thanks for the test case.

ollydbg · « **Reply #35 on:** October 30, 2011, 02:58:00 am »

@obf, Is it possible to use a macro in the below edit dialog?

see the image:

Thanks.

BTW:
For those who use a more recent gcc (like gcc 4.5, 4.6, or 4.7), you may experience a very annoying debug experience when you debugger leave the scope, you will jump to some line of your local variable declaration.

See:
Why running the next command will jump back to the previous line positio and the following posts. It looks like its a bug in GCC Bug 49951 – [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0.

As a result, I'm returning to use a mingw gcc 4.4.5 version again.

Oleg_Sam · « **Reply #36 on:** October 30, 2011, 10:37:17 am »

http://forums.codeblocks.org/index.php/topic,15139.30.html

oBFusCATed · « **Reply #37 on:** October 31, 2011, 10:34:10 am »

Quote from: ollydbg on October 30, 2011, 02:58:00 am

As a result, I'm returning to use a mingw gcc 4.4.5 version again.

It is not that bad, sometimes it could be useful

I know about the patch, but I've not tested it yet.

ollydbg · « **Reply #38 on:** October 31, 2011, 11:39:30 am »

Quote from: oBFusCATed on October 31, 2011, 10:34:10 am

I know about the patch, but I've not tested it yet.

what does this sentence means???

Quote from: oBFusCATed on October 31, 2011, 10:34:10 am

Quote from: ollydbg on October 30, 2011, 02:58:00 am
As a result, I'm returning to use a mingw gcc 4.4.5 version again.
It is not that bad, sometimes it could be useful

If we use gdb command line, then it is not bad, but if the caret jump wildly in your c::b editor, it is too bad.

oBFusCATed · « **Reply #39 on:** October 31, 2011, 12:30:19 pm »

Quote from: ollydbg on October 31, 2011, 11:39:30 am

what does this sentence means???

It is an answer to Oleg_Sam's post.

oBFusCATed · « **Reply #40 on:** November 12, 2011, 02:14:06 am »

Morten, Jens: The "No executable file specified." should be fixed in r7585. Please test.

oBFusCATed · « **Reply #41 on:** November 12, 2011, 11:35:15 am »

Quote from: ollydbg on October 30, 2011, 02:58:00 am

@obf, Is it possible to use a macro in the below edit dialog?

In r7586, you can now

Thank you Oleg_Sam.

ollydbg · « **Reply #42 on:** November 13, 2011, 02:58:34 am »

Quote from: oBFusCATed on November 12, 2011, 11:35:15 am

Quote from: ollydbg on October 30, 2011, 02:58:00 am
@obf, Is it possible to use a macro in the below edit dialog?
In r7586, you can now
Thank you Oleg_Sam.

Thank you obf and oleg_sam!!!

Jenna · « **Reply #43 on:** November 15, 2011, 07:51:47 am »

Quote from: oBFusCATed on November 12, 2011, 02:14:06 am

Morten, Jens: The "No executable file specified." should be fixed in r7585. Please test.

Sorry for the late reply.
Stoping gdb works now (only tested on linux).

playxiaobaicai · « **Reply #44 on:** January 08, 2012, 05:05:44 pm »

Thank you killerbot!

News:

Author Topic: The 17 September 2011 build (7452) DEBUGGER BRANCH version is out. (Read 76545 times)