Author Topic: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.  (Read 46988 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5519
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_wx2810_gcc451-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_gcc451-TDM.7z

The 06 March 2011 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20110306_rev7040_DEBUGGER_BRANCH_win32.7z
  - Linux :
   none

Important changes compared to previous DEBUGGER BRANCH nightly:

* debugger_branch: applied patch dbg_refactor0019.3 with the following features:
- remove "Debug-> Edit Watches...", it was unused
- fixed the OnUpdateUI methods: if there was no active debugger all controls were active, now all controls are disabled
* debugger branch: applied (modified) patch dbg_refactor0019.4:
- removed DebuggerTree and related artifacts as they are no longer needed (clean-up)
* debugger branch: applied patch dbg_refactor0019.5 with the following features:
- step into was not working on windows (the code was different on windows/mac and linux, now it is the same on all platforms)
- marked on of the reg expressions to use the wxRE_ADVANCED
* debugger branch: applied patch dbg_refactor0019.6 with the following features:
- re-factored a bit the stack frame parsing code (extracted it in a function)
- another case of stack frame output is parsed correctly ("#11 0x00406810 in main ()")
- added tests for stack frame parsing
- re-factored a bit the debuggergdb test project
* 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.

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.
« Last Edit: March 06, 2011, 07:59:23 pm by killerbot »

Offline madnut.ua

  • Multiple posting newcomer
  • *
  • Posts: 13
  • something mad...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5519
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #2 on: March 06, 2011, 07:59:38 pm »
corrected, thanks for mentioning.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #3 on: March 07, 2011, 06:52:58 am »
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/ .

Offline huzhongshan

  • Multiple posting newcomer
  • *
  • Posts: 110
build 7040 debug branch may have some bugs.
« Reply #4 on: March 08, 2011, 10:27:19 am »
I installed 7040 instead of 7017  today , but I found that the 7040 cannot set break point in my dll project . I debug a dll written in gcc by using a host application written by visual c++ 6.  When I set break point in dll , and debug , it freezed.

I reinstall 7017 , the debug works  fine.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: build 7040 debug branch may have some bugs.
« Reply #5 on: March 08, 2011, 10:59:25 am »
Please give more details...
What is your gdb version?
Can you replicate the problem in a simpler project?
Can you provide the debugger's debug logs in both versions or a backtrace of the freeze?

Can you hide your callstack/backtrace window and try again?

p.s. please use the topic for the nightly that has the bug...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: build 7040 debug branch may have some bugs.
« Reply #6 on: March 08, 2011, 11:04:17 am »
Give your feedback on this version only in this thread, don't mix it with the regular nightly please.

p.s. please use the topic for the nightly that has the bug...

I moved the new topic into this thread.

Offline huzhongshan

  • Multiple posting newcomer
  • *
  • Posts: 110
Re: build 7040 debug branch may have some bugs.
« Reply #7 on: March 08, 2011, 03:14:15 pm »
Please give more details...
What is your gdb version?
Can you replicate the problem in a simpler project?
Can you provide the debugger's debug logs in both versions or a backtrace of the freeze?

Can you hide your callstack/backtrace window and try again?

p.s. please use the topic for the nightly that has the bug...

Which part of the logs will help to find the problem ? I am new to gdb.
I just find that It works well in 7017 , works bad in 7040.
I revert to 7017 after several times to try 7040 , and 7017 does work well.


Offline huzhongshan

  • Multiple posting newcomer
  • *
  • Posts: 110
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #8 on: March 08, 2011, 03:36:43 pm »
Breakpoint 1, GetImageWithR (ColorBuf={p_Img = 0xa6b0040 "\215\215y\217\217{\223\225\200\222\224\177\230\217~\230\217~\233\214\222\235\216\224\226\220\205\231\223\210\232\215\226\230\213\224\233\214\210燶221\215\230\220\213\221\211\204\227\221w\231\223y\233\220\203\231\216\201\227\216\222\230\217\223\227\224\216\224\221\213\226\215\203\227\216\204\235\223\221\234\222\220\233\212v224\200\235\223\212\230\216\205\217\220\201\220\221\202\222\216\200\222\216\200\220\216\200\221\217\201\221\224|\221\224|\222\217\210\226\223\214\224\215\21..................................................(do not paste )

I found that gdb print the input parameters of functions , but I write image algorithm , and the image buf is very very large.
maybe it caused some problems?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #9 on: March 08, 2011, 09:36:56 pm »
Can you provide a simpler project, which demonstrates the problem?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Borr

  • Multiple posting newcomer
  • *
  • Posts: 29
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #10 on: March 11, 2011, 08:25:07 am »
I have a Unicode build wxWidgets 2.8.10, gdb-7.2.50.20101213 with python, MinGW 4.4.1, OS: WinXP SP3
system cp1251; C::B UTF-8; console cp866.

(gdb) show charset
The host character set is "auto; currently CP1251".
The target character set is "auto; currently CP1251".
The target wide character set is "auto; currently UTF-16".

My problem is that I can debug wxString (not English). In the debug window I can see is not readable symbols. With 7017 everything is works.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #11 on: March 11, 2011, 10:16:04 am »
As I've said in the other thread, what is the encoding of your string? The encoding of C::B is Utf8/16 (not sure how it is on windows, thought).

Also what happens, when you debug this with pure command line gdb?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Borr

  • Multiple posting newcomer
  • *
  • Posts: 29
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #12 on: March 11, 2011, 10:30:16 am »
Quote
As I've said in the other thread, what is the encoding of your string?

C::B encode UTF-8

From command line all works fine. With the same debugger gdb-7.2.50, svn 7017 works fine.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #13 on: March 11, 2011, 11:14:40 am »
It seems you're not understanding what I'm writing you, but it is OK.
Can you paste (using code tags) the debugger's debug log from both versions?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Borr

  • Multiple posting newcomer
  • *
  • Posts: 29
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #14 on: March 11, 2011, 01:10:49 pm »
Quote
It seems you're not understanding what I'm writing you, but it is OK.

Quite possibly. I do not speak English

svn 7017
Code
PATH=.;D:\wxMSW-2.8.10\lib\gcc_dll;C:\MinGW_441\bin;C:\FkClnt1\USER;C:\FkClnt1\SYSTEM;C:\Program Files\PC Connectivity Solution\;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\;F:\Borland\CBUILD~1\Bin;F:\Borland\CBUILD~1\Projects\Bpl;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Intel\DMIX;C:\Program Files\IVT Corporation\BlueSoleil\Mobile;D:\Qt\4.5.2\qt\bin;C:\Program Files\Cppcheck\;C:\Program Files\Calibre2\;D:\Мои документы\Borland Studio Projects\Bpl;D:\wxMSW-2.8.10\lib\gcc_dll;D:\Project\FB205_emb;D:\Qt\4.5.2\qt\bin;C:\MinGW_441\mingw32\bin
Command-line: C:\MinGW_441\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/DebugTest.exe
Working dir : D:\Proba\DebugTest\
> set prompt >>>>>>cb_gdb:
Reading symbols from D:\Proba\DebugTest/bin/Debug/DebugTest.exe...
done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source C:\Program Files\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory D:/Proba/DebugTest/
>>>>>>cb_gdb:
> break "D:/Proba/DebugTest/DebugTestMain.cpp:84"
Breakpoint 2 at 0x402019: file D:\Proba\DebugTest\DebugTestMain.cpp, line 84. (2 locations)
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 3612.0xbf0]
LOAD_DLL_DEBUG_EVENT)
Breakpoint 2, DebugTestDialog::DebugTestDialog (this=0x22fb14, parent=0x0, id=-1) at D:\Proba\DebugTest\DebugTestMain.cpp:84
D:\Proba\DebugTest\DebugTestMain.cpp:84:3282:beg:0x402cfd
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> info locals
StaticText1Font = {
  <wxFontBase> = {
    <wxGDIObject> = {
      <wxObject> = {
        _vptr.wxObject = 0x673f1bc8,
        static ms_classInfo = {
          m_className = 0x673024a6 L"wxObject",
          m_objectSize = 8
,
          m_objectConstructor = 0,
          m_baseInfo1 = 0x0,
          m_baseInfo2 = 0x0,
          static sm_first = 0x673f6050,
          m_next = 0x673f9eb0,
          static sm_classTable = 0x5329a8
        },
        m_refData = 0xb58e58
      },
      members of wxGDIObject:
      static ms_classInfo = {
        m_className = 0x67342b14 L"wxGDIObject",
        m_objectSize = 8,
        m_objectConstructor = 0x66f0544a <wxGDIObject::wxCreateObject()>,
        m_baseInfo1 = 0x673f9e30,
        m_baseInfo2 = 0x0,
        static sm_first = 0x673f6050,
        m_next = 0x6741f820,
        static sm_classTable = 0x5329a8
      }
    },
    members of wxFontBase:
    static ms_encodingDefault = wxFONTENCODING_SYSTEM
  },
  members of wxFont:
  static ms_classInfo = {
    m_className = 0x6731b040 L"wxFont",
    m_objectSize = 8,
    m_objectConstructor = 0x66e3780a <wxFont::wxCreateObject()>,
    m_baseInfo1 = 0x6741f6c0,
    m_baseInfo2 = 0x0,
    static sm_first = 0x673f6050,
    m_next = 0x673fb1b8,
    static sm_classTable = 0x5329a8
  }
}
test = {
  <wxStringBase> = {
    static npos = 4294967295,
    m_pchData = 0x530000 L"\310\000"
  }, <No data fields>}
i = 2498315
>>>>>>cb_gdb:
> info args
this = 0x22fb14
parent = 0x0
id = -1
>>>>>>cb_gdb:
> next
D:\Proba\DebugTest\DebugTestMain.cpp:85:3319:beg:0x402d10
>>>>>>cb_gdb:
> info locals
StaticText1Font = {
  <wxFontBase> = {
    <wxGDIObject> = {
      <wxObject> = {
        _vptr.wxObject = 0x673f1bc8,
        static ms_classInfo = {
          m_className = 0x673024a6 L"wxObject",
          m_objectSize = 8,
          m_objectConstructor = 0,
          m_baseInfo1 = 0x0,
          m_baseInfo2 = 0x0,
          static sm_first = 0x673f6050,
          m_next = 0x673f9eb0,
          static sm_classTable = 0x5329a8
        },
        m_refData = 0xb58e58
      },
      members of wxGDIObject:
      static ms_classInfo = {
        m_className = 0x67342b14 L"wxGDIObject",
        m_objectSize = 8,
        m_objectConstructor = 0x66f0544a <wxGDIObject::wxCreateObject()>,
        m_baseInfo1 = 0x673f9e30,
        m_baseInfo2 = 0x0,
        static sm_first = 0x673f6050,
        m_next = 0x6741f820,
        static sm_classTable = 0x5329a8
      }
    },
    members of wxFontBase:
    static ms_encodingDefault = wxFONTENCODING_SYSTEM
  },
  members of wxFont:
  static ms_classInfo = {
    m_className = 0x6731b040 L"wxFont",
    m_objectSize = 8,
    m_objectConstructor = 0x66e3780a <wxFont::wxCreateObject()>,
    m_baseInfo1 = 0x6741f6c0,
    m_baseInfo2 = 0x0,
    static sm_first = 0x673f6050,
    m_next = 0x673fb1b8,
    static sm_classTable = 0x5329a8
  }
}
test = {
  <wxStringBase> = {
    static npos = 4294967295,
    m_pchData = 0xb580bc L"Проба"
  }, <No data fields>}
i = 2498315
>>>>>>cb_gdb:
> info args
this = 0x22fb14
parent = 0x0
id = -1
>>>>>>cb_gdb:

svn 7040_debug
Code
PATH=.;D:\wxMSW-2.8.10\lib\gcc_dll;C:\MinGW_441\bin;C:\FkClnt1\USER;C:\FkClnt1\SYSTEM;C:\Program Files\PC Connectivity Solution\;C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\;F:\Borland\CBUILD~1\Bin;F:\Borland\CBUILD~1\Projects\Bpl;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Intel\DMIX;C:\Program Files\IVT Corporation\BlueSoleil\Mobile;D:\Qt\4.5.2\qt\bin;C:\Program Files\Cppcheck\;C:\Program Files\Calibre2\;D:\Мои документы\Borland Studio Projects\Bpl;D:\wxMSW-2.8.10\lib\gcc_dll;D:\Project\FB205_emb;D:\Qt\4.5.2\qt\bin;C:\MinGW_441\mingw32\bin
Command-line: C:\MinGW_441\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/DebugTest.exe
Working dir : D:\Proba\DebugTest\
> set prompt >>>>>>cb_gdb:
Reading symbols from D:\Proba\DebugTest/bin/Debug/DebugTest.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-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:
> directory D:/Proba/DebugTest/
>>>>>>cb_gdb:
> break "D:/Proba/DebugTest/DebugTestMain.cpp:84"
Breakpoint 2 at 0x402019: file D:\Proba\DebugTest\DebugTestMain.cpp, line 84. (2 locations)
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 1044.0xdd8]
Breakpoint 2, DebugTestDialog::DebugTestDialog (this=0x22fb14, parent=0x0, id=-1) at D:\Proba\DebugTest\DebugTestMain.cpp:84
D:\Proba\DebugTest\DebugTestMain.cpp:84:3282:beg:0x402cfd
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> whatis &test
type = wxString *
>>>>>>cb_gdb:
> output /c test.m_pchData[0]@((wxStringData*)test.m_pchData - 1)->nDataLength
Cannot access memory at address 0x52fff8
>>>>>>cb_gdb:
> next
D:\Proba\DebugTest\DebugTestMain.cpp:85:3319:beg:0x402d10
>>>>>>cb_gdb:
> whatis &test
type = wxString *
>>>>>>cb_gdb:
> output /c test.m_pchData[0]@((wxStringData*)test.m_pchData - 1)->nDataLength
{31 '\037', 64 '@', 62 '>', 49 '1', 48 '0'}>>>>>>cb_gdb:

And one more thing: If you close the C::B with a running debugger C::B closes with an error (only svn 7017)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #15 on: March 11, 2011, 01:35:12 pm »
Please post the long from debuggers branch 7017...
Or add your variable as a watch in the normal nightly.
It seems the locals work, but there the debugger scripts are not working.

Read this: http://wiki.codeblocks.org/index.php?title=Debugger_scripts and probably try to disable the debug scripts for wxString.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Borr

  • Multiple posting newcomer
  • *
  • Posts: 29
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #16 on: March 11, 2011, 02:31:19 pm »
You are right. Now and in the KB, I got the same result.

Quote
output /c test.m_pchData[0]@((wxStringData*)test.m_pchData - 1)->nDataLength

the result is not readable character set - {31 '\037', 64 '@', 62 '>', 49 '1', 48 '0'}>>>>>>cb_gdb:

Code
> p test.m_pchData[0]@((wxStringData*)test.m_pchData - 1)->nDataLength

shows what i need - $2 = L"Проба"

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #17 on: March 11, 2011, 02:47:11 pm »
Find the gdb_types.script and remove the function call which registers the wxString handling, after that it will probably work correctly.

For best results you'll need the python pretty printers for wxWidgets...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Borr

  • Multiple posting newcomer
  • *
  • Posts: 29
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #18 on: March 11, 2011, 03:01:13 pm »
with rev7017 I have no problems. 7040_deb does not show local variables(http://forums.codeblocks.org/index.php?action=dlattach;topic=14334.0;attach=5344;image). shows only those variables that I added. change the script does not work as a result of just an empty string. The results of python pretty printers for wxWidgets do not fall into the Watches (7040_deb)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6035
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #19 on: March 11, 2011, 03:09:07 pm »
Find the gdb_types.script and remove the function call which registers the wxString handling, after that it will probably work correctly.

For best results you'll need the python pretty printers for wxWidgets...
totally agree!!!

and for pretty printer for wx, see my wiki pages on that site:
http://code.google.com/p/qp-gcc/

PS: I can't access to that site because the earth quake in Japan break some lines from China :(.

« Last Edit: March 11, 2011, 03:15:44 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #20 on: March 11, 2011, 03:26:22 pm »
with rev7017 I have no problems. 7040_deb does not show local variables(http://forums.codeblocks.org/index.php?action=dlattach;topic=14334.0;attach=5344;image). shows only those variables that I added. change the script does not work as a result of just an empty string. The results of python pretty printers for wxWidgets do not fall into the Watches (7040_deb)
With rev7017 you'll have the same problem, when you use "add watch" ...
Local vars are useful, but a bit limiting and at the moment are not implemented in the debuggers branch...

Also are you sure you've removed the call? Have you tried to restart C::B (not sure if it is needed).
What is the result of the "print test" gdb command?

The pretty printers change the output of the print/output gdb commands and that are the commands used to get the values for the watches.

See the sait Ollydbg mentioned.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5519
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #21 on: March 11, 2011, 03:46:28 pm »
Quote
Local vars are useful, but a bit limiting and at the moment are not implemented in the debuggers branch...

Since we are thinking of merging the debugger branch to trunk, I personally think this is something that should be fixed asap. This seems a show stopper to me.
I don't think I can convince anyone, of all our improvements if even a local variable can not be watched.
[or am I misinterpreting the quote above ??]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #22 on: March 11, 2011, 04:07:49 pm »
killerbot:
Hm, you prefer the old unusable watches which had the almost unusable local variables, over the new usable watches which don't have them?

The reason for the missing local vars/func args, as I've stated many times, is that I want to have them in separate windows. I want something like, what is done in VStudio.
But at the moment I think it is not possible. I want to be able to move a window from one notebook to another, but last time I've checked wxAUI didn't support this feature.

p.s. we are talking about the automatic local variables, you can watch local variables but you should add them manually...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5519
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #23 on: March 12, 2011, 09:18:08 am »
Quote
p.s. we are talking about the automatic local variables, you can watch local variables but you should add them manually...

ok, that's why is was asking. This makes already much more sense :-)

And I do prefer the new way of course. I hope we will be able to have automatic ones too, if we can solve the technical issue you mention.

Offline Borr

  • Multiple posting newcomer
  • *
  • Posts: 29
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #24 on: March 12, 2011, 10:09:20 am »
svn 7017
One more thing, if you close the CB in advanced debugging. CB closes with an error, of the advanced settings for the debugger in the CB are not saved.

svn 7017_7040 and add watches:
I changed the script it solved the problem for me
Code
//in Evaluate_wxString change
local result = _T("output /c ") + a_str + oper + _T("m_pchData[") + start + _T("]@");
//to
local result = _T("output /s ") + a_str + oper + _T("m_pchData[") + start + _T("]@");

function Parse_wxString(a_str, start)
{
  local result = a_str;
  return result;
}

Debugger run as

Code
source C:\MinGW_441\bin\wx.gdb
set print element 0

Offline Manolo

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #25 on: March 13, 2011, 09:01:04 pm »
Hello to you all. Good work.
A comment:
My enviroment is XP SP3, MinGW, GDB.
I set a breakpoint with 'properties' so it will stop when 'var==1000', debug-running becomes sloooow.
I notice gdb is consuming about 45% of CPU, C:B about 25% and my app only 2%. I activate 'Debugger(debug)' tab window and see how it's continuosly updating with messages:
Quote
kernel event for pid=3096 tid=fc8 code=EXCEPTION_DEBUG_EVENT)
e=EXCEPTION_DEBUG_EVENT)
ContinueDebu
gEvent (cpid=3096, ctid=fc8, DBG_CONTINUE);
INUE);
 tid=fc8 code=EXCEPTION_DEBUG_EVENT)
c8, DBG_CONTINUE);
for pid=3096 tid=fc8 code=EXCEPTION_DEBUG_EVENT)
EBUG_EVENT)
3096, ctid=fc8, DBG_CONTINUE);
ernel event for pid=3096 tid=fc8 code=EXCEPTION_DEBUG_EVENT)
=EXCEPTION_DEBUG_EVENT)
nt for pid=3096 tid=fc8 code=EXCEPTION_DEBUG_EVENT)
ContinueDebug
Event (cpid=3096, ctid=fc8, DBG_CONTINUE);
NUE);
tid=fc8 code=EXCEPTION_DEBUG_EVENT)
C
ontinueDebugEvent (cpid=3096, ctid=fc8, DBG_CONTINUE);
8, DBG_CONTINUE);
IMHO, all these prompts are not interesting but just before the debugger stops at my breakpoint because that var's condition.
Also note that in each iteration at least the initial character of the prompt is "eaten".

TIA
Manolo

Offline Manolo

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #26 on: March 13, 2011, 09:16:44 pm »
Hello again.
Other point when debugging is about watches window.
I have a class with a member that is an array. Because I want to watch that array, I watch the class, look for the address of that array and open the 'Examine memory' window for that address.
Other way is at the watching window: I can set properties for my class (or 'rename') to myclass.myarray and watch it. But I would prefer to see inside the watch window some part of that array, with just some kind of click on my array member (i.e. setting also properties for that member).

Thanks
Manolo

Offline Manolo

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #27 on: March 13, 2011, 09:35:54 pm »
Hello, twice again.
I don't know if this thread is the right for this question or if it is a gdb bug...

I set only one breakpoint, start, and the run stops at it. OK.
Now I use the 'Next line' button (or F7) and gdb complains:
Quote
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -127.
Error accessing memory address 0x7816cd30: Input/output error.
Cannot insert breakpoint -126.
Error accessing memory address 0x7c343646: Input/output error.
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -131.
Error accessing memory address 0x7816cd30: Input/output error.
I searched for this in the web. I found a possible gdb's bug about
"PIE (Position Independent Executable), which GDB does NOT currently support"
I don't know how to cope with this.

TIA
Manolo

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #28 on: March 13, 2011, 10:07:47 pm »
Reply in reverse order:

to post3: Check if you're using -fPIE to compile your application, if you're using it please remove it.

to post2: To watch arrays without size ( the array declaration is not T a[size]), you have to add the my_struct.my_array to the watches and then set the properties for the watch to be 'watch as array' and dial an appropriate count.

to post1:
Are you using a quad core processor?
Can you reproduce this problem with simple console hello world project?
Can you set the condition to var==10 and then paste the debugger's debug log?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Manolo

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #29 on: March 15, 2011, 12:42:23 am »
Post 3: Activating 'Complier loggin: full command line' I don't see -fPIE

Post 2: You are saying what I said. I asked for simplifying it setting also properties for dereferenced members in watch window.

Post 1:
I'm using an old AMD 3200
Here's is simple code:
Code
#include <iostream>
using namespace std;
int main()
{
    int var, res=0;
    for (var=0; var<1000; var++)
        res +=var; //set breakpoint here
    cout << res;
    return 0;
}
The full command line:
Quote
mingw32-g++.exe -Wall -fexceptions  -g    -IC:\MinGW\include  -c C:\PROGS\pruebas\hello\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -LC:\MinGW\lib  -o bin\Debug\hello.exe obj\Debug\main.o   
Información: se resuelve std::cout  al enlazar con __imp___ZSt4cout (auto-importación
c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: aviso: la importación automática se activó sin especificar --enable-auto-import en la línea de órdenes.
Esto debe funcionar a menos que involucre estructuras de datos constantes que referencíen símbolos de DLLs auto-importadas.
)
Output size is 37.44 KB
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings (0 minutes, 1 seconds)
 
I set the breakpoint and edit it's properties:
"Enabled" and "Break when expresion is true" and the expresion is var==10
Now I use F8 (Start) and here is the debugger output:
Quote
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\PROGS\pruebas\hello\
Adding source dir: C:\PROGS\pruebas\hello\
Adding file: bin\Debug\hello.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2
Child process PID: 2760
Program exited normally.
Debugger finished with status 0
And the long output (I skip my long PATH):
Quote
Command-line: C:\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/hello.exe
Working dir : C:\PROGS\pruebas\hello\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\PROGS\pruebas\hello/bin/Debug/hello.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined.
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source C:\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/PROGS/pruebas/hello/
>>>>>>cb_gdb:
> break "C:/PROGS/pruebas/hello/main.cpp:6"
Breakpoint 2 at 0x4013d6: file C:\PROGS\pruebas\hello\main.cpp, line 6.
>>>>>>cb_gdb:
> condition 2 var==10
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 488.0x604]
Program exited normally.
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> quit
As you can see, it doesn't stop!
I change expresion to res>20 and try again with the same no-stop result.
No, I can't reproduce my first post problem with this simple code. But now it's a different problem.

TIA
Manolo

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #30 on: March 15, 2011, 08:37:42 am »
Post2: Won't happen with the current plugin, sorry... If you feel it is doable, patches welcome
Post1: Probably this is the problematic command: "set debugevents off", it is sent to late in the original example.

p.s. don't use localized compiler it can confuse C::B
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Manolo

  • Multiple posting newcomer
  • *
  • Posts: 47
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #31 on: March 15, 2011, 09:05:17 pm »
Quote
p.s. don't use localized compiler it can confuse C::B
This is a very interesting note to advise to every one using C:B and MinGW.
I used MinGW-Get. If I recall well, it installs localization automatically.

Thanks
Manolo

Offline ironhead

  • Almost regular
  • **
  • Posts: 210
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #32 on: March 15, 2011, 11:21:27 pm »
Quote
p.s. don't use localized compiler it can confuse C::B
This is a very interesting note to advise to every one using C:B and MinGW.
I used MinGW-Get. If I recall well, it installs localization automatically.

It does, but it doesn't mean it will be used.

I assume the localization issue is due to the fact that C::B does pattern matching on the errors / warnings that gcc/g++ outputs and that it does this pattern matching based on the English translations?

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7252
Re: The 06 March 2011 build (7040) DEBUGGER BRANCH version is out.
« Reply #33 on: March 15, 2011, 11:49:37 pm »
I assume the localization issue is due to the fact that C::B does pattern matching on the errors / warnings that gcc/g++ outputs and that it does this pattern matching based on the English translations?
That's correct.