Author Topic: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.  (Read 14078 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #15 on: November 30, 2010, 03:18:18 pm »
what about grouping all the debug related ones in a submenu Debug in the right click context menu (toggle breakpoint , run to cursor,  set next statement) ?
No :) this will make them harder to use...

Could we hide the remote console on MSW with something like the following:
Does stopping the debuggee works if the console is hidden? If it works I have nothing against it :)

"Step Into" is enabled, runs the debugger but does not break the program.

Why is "Step Into" enabled before running the debugger?
Debug log please...
<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline cbexaminr

  • Advanced newcomer
  • *
  • Posts: 104
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #16 on: November 30, 2010, 03:55:15 pm »
[deleted]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 1990
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #17 on: November 30, 2010, 07:22:00 pm »
Could we hide the remote console on MSW with something like the following:
Quote
Does stopping the debuggee works if the console is hidden? If it works I have nothing against it :)
Yep, the double bar on the debugger tool bar breaks just fine with the patch.

"Step Into" is enabled, runs the debugger but does not break the program.

Why is "Step Into" enabled before running the debugger?
Quote
Debug log please...
This log is from a MSW simple wxWidgets Hello world, a rebuild, then a hit on the "Step Into" button.

Debugger log
Code: [Select]
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\temp\Test\
Adding source dir: C:\temp\Test\
Adding file: .\debug\Test.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.0
Child process PID: 4520

Debugger debug log
Code: [Select]
PATH=.;C:\Usr\Proj\wxWidgets2810\lib\gcc_lib;C:\Usr\mingw431\bin;C:\Usr\Proj\ImageCraft\ImageCraft_ARM\trunk\src\output;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Dell\Dell Wireless WLAN Card;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\usr\bin;C:\Program Files (x86)\CollabNet Subversion;C:\Program Files (x86)\TortoiseSVN\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Common Files\Adobe\AGL
Command-line: C:\Usr\mingw431\bin\gdb.exe -nx -fullname  -quiet -args ./debug/Test.exe
Working dir : C:\temp\Test\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\temp\Test/./debug/Test.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 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:
> source c:\Usr\Proj\cbDebug\trunk\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/temp/Test/
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 4768.0x2dc]

« Last Edit: November 30, 2010, 07:33:02 pm by Pecan »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #18 on: November 30, 2010, 08:21:45 pm »
Pecan: Thanks this is a regression caused by the 17.7 patch. I'll look into it.
<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #19 on: December 03, 2010, 05:11:50 pm »
BTW: Can someone try to reproduce this bug:

1. Start debugger
2. Break on some breakpoint
3. Show and dock the watches window
4. Select something in the editor
5. Drag and drop the selection in to the empty item at the bottom of the watches window

The result is that the drag'n'drop operation is cut not copy and the selected text is deleted from the editor.
I've successfully reproduced this bug on two linux machines:
1. gentoo amd64 unstable (gcc 4.4.5 + wxGTK 2.8.11)
2. fedora 8 amd64 inside vmware player (this machine was given to me and I don't know how updated it is)
Code: [Select]
[root@localhost ~]# rpm -qa | grep wx
wxGTK-2.8.9-1.fc8
wxGTK-gl-2.8.9-1.fc8
wxGTK-devel-2.8.9-1.fc8
wxBase-2.8.9-1.fc8

[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# cat /etc/redhat-release
Fedora release 8 (Werewolf)

<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 6665
    • Jens unofficial debian-repository for the Code::Blocks - IDE
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #20 on: December 03, 2010, 07:32:48 pm »
BTW: Can someone try to reproduce this bug:

I can not reproduce it on debian 64-bit unstable, wx2.8.10, gcc 4.5.1.
Regards

Jens  Debian - nightlies (and release) : http://apt.jenslody.de/ Fedora [18 - 20]- and CentOS/RedHat [5, 6 & 7] - nightlies : http://rpm.jenslody.de/

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #21 on: December 03, 2010, 08:42:29 pm »
Jens: I know, can you try on Suse, Fedora (if you have VMs for them)?
<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline MaxGaspa

  • Advanced newcomer
  • *
  • Posts: 116
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #22 on: December 12, 2010, 05:13:38 pm »
Dear devs,

I'm reporting a ugly behavior (IMO) of the new debugger interface (I don't remember if I met the same issue with the old interface). I would say it's a bug...

I was debugging a code using a vector of double (20k element) and watching the array I've got two different behavior.

I the first case, the working one, the debugger log is saying

> whatis &x
type = vector *
>>>>>>cb_gdb:
> output x
{
  <_Vector_base> = {
    _M_impl = {
      <allocator> = {
        <new_allocator> = {<No data fields>}, <No data fields>},
      members of _Vector_base::_Vector_impl:
      _M_start = 0x1204d88,
      _M_finish = 0x122be80,
      _M_end_of_storage = 0x1244d88
    }
  }, <No data fields>}>>>>>>cb_gdb:
> cont

and everything works right, I'm able to see the popup window and to watch the array in the watch window.

In the second case I've got

> whatis &x
type = std::vector<double, std::allocator<double> > *
>>>>>>cb_gdb:
> pvector x
elem[0]: $1 = 0.97340000000000004
elem[1]: $2 = 1.0048000000000001
elem[2]: $3 = 1.0362
elem[3]: $4 = 1.0676000000000001
.
.
.

The output log from the debugger is listing all the elements, the cpu was going to 100% and CB seems frozen.

In both case x is a local std::vector<double>. The only difference is that the first 'x' belongs to the main program I was debugging, the second 'x' belongs to a method of a class contained in a static library I linked to the program.

Because it happens to put the cursor over a such variable, just moving the mouse, in some case I've got
the CB frozen even if I had't the intention to debug the vector.

This is ugly  :D

Hope this helps.

Max
 

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #23 on: December 12, 2010, 05:37:29 pm »
I've hit this bug, too... and it is a bit complex:

1. gdb doesn't know if a variable is initialized, so adding uninitialized vector to the watches cause CB to lock up (hovering on it, too)
2. cb doesn't limit the result set and I'm not sure if it could be fixed easily in the current non MI version of the plugin
3. it is present in the trunk version, because vector handling is not much different.

If you have time and energy you can look in stl-views-1.0.3.gdb for a way to limit the results returned from the pvector command.
Probably we should disable the usage of pvector in python enabled gdb's...
<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4184
  • Interests on OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #24 on: December 13, 2010, 01:18:00 am »
1. gdb doesn't know if a variable is initialized, so adding uninitialized vector to the watches cause CB to lock up (hovering on it, too)

this is annoying bug, I have several bug report:

see:
http://sourceware.org/bugzilla/show_bug.cgi?id=12127
http://sourceware.org/bugzilla/show_bug.cgi?id=11407

and there are some discussion on the gdb maillist.
it is hard to detect a variable is initialized or not, even it was initialized, then later it can be destroyed. I have a patch to solve partially when showing the local variables patch. see:
http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c33

but that doesn't solve every thing. I'm wondering how it was done in other debugger like MSVC debugger???
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: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #25 on: December 13, 2010, 08:26:34 am »
They use limits in their GUI, the same is possible with GDB/MI :)
<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4184
  • Interests on OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #26 on: December 13, 2010, 08:28:52 am »
They use limits in their GUI, the same is possible with GDB/MI :)
You mean MSVC debugger use limits when showing an uninitialized vector??
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: 7788
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #27 on: December 13, 2010, 09:26:13 am »
Their array control has a limit + scrolling...
Also they init variables with some magic numbers 0xfefefefe,0xabababab,0xcccccccc and it is possible that they use them to fix such problems...
<debugger plugin maintainer>
(most of the time I ignore long posts)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 4184
  • Interests on OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #28 on: December 13, 2010, 09:37:42 am »
Their array control has a limit + scrolling...
Also they init variables with some magic numbers 0xfefefefe,0xabababab,0xcccccccc and it is possible that they use them to fix such problems...
yes, I totally agree with you!!!
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.