User forums > Nightly builds

The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.

<< < (5/6) > >>

Jenna:

--- Quote from: oBFusCATed on December 03, 2010, 05:11:50 pm ---BTW: Can someone try to reproduce this bug:

--- End quote ---

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

oBFusCATed:
Jens: I know, can you try on Suse, Fedora (if you have VMs for them)?

Max:
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
 

oBFusCATed:
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...

ollydbg:

--- Quote from: oBFusCATed on December 12, 2010, 05:37:29 pm ---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)

--- End quote ---

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???

Navigation

[0] Message Index

[#] Next page

[*] Previous page