Bug 257834 - Unable to expand both "first" and "second" members of the pair<> in Variables window
Summary: Unable to expand both "first" and "second" members of the pair<> in Variables...
Status: RESOLVED UPSTREAM
Alias: None
Product: kdevelop
Classification: Applications
Component: CPP Debugger (show other bugs)
Version: 4.1.60
Platform: Debian unstable Linux
: VHI major
Target Milestone: 4.2.0
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-24 23:04 UTC by Valentyn Pavliuchenko
Modified: 2011-11-20 22:42 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Snapshot of the failing case (84.86 KB, image/png)
2010-11-24 23:04 UTC, Valentyn Pavliuchenko
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Valentyn Pavliuchenko 2010-11-24 23:04:41 UTC
Created attachment 53709 [details]
Snapshot of the failing case

Version:           4.1.60 (using KDE 4.5.1) 
OS:                Linux

Complex objects used as "first" or "second" of the std::pair<> are unexpandable in Variables window.

Reproducible: Didn't try

Steps to Reproduce:
The following code shows a problem:

vector<int> vec;
vec.push_back(1);
vec.push_back(2);
pair<vector<int>, vector<int> > a(pair<vector<int>,vector<int> >(vec, vec));
return 0;

Create a breakpoint on the "return 0;" line and try to expand variable "a". Both first and second will be shown as "{...}" but nothing will be expandable.
Comment 1 Valentyn Pavliuchenko 2010-11-24 23:05:59 UTC
Sorry, "Reproducible" must be "Always"
Comment 2 Andrey 2011-01-27 22:07:06 UTC
Similar problems with std::map and std::string containers:

#include <map>
#include <list>
#include <string>
using namespace std;

int main()
{
    typedef map<string, list<string> > map_t;
    map_t m;
    m["one"].push_back("a");
    m["one"].push_back("b");
    m["one"].push_back("c");
    m["two"].push_back("1");
    m["two"].push_back("2");
    m["two"].push_back("3");
    map_t::const_iterator i = m.begin();
    i++;
    return 0; // <= break point on this line
              // neither "m" nor "i" are displayed in correct way
}
Comment 3 Milian Wolff 2011-01-28 12:06:56 UTC
confirmed with the testcase from andrey, using the gdb command line works properly though: both print i and m will show the expected results (if you setup python pretty printers properly).
Comment 4 Kostik Karganov 2011-02-02 13:00:43 UTC
GDB behaves differently for MI command and user command, feel the difference:

(gdb) print m
print m
$3 = std::map with 2 elements = {
["one"] = std::list = {
[0] = "a",
[1] = "b",
[2] = "c"
},
["two"] = std::list = {
[0] = "1",
[1] = "2",
[2] = "3"
}
}
^done

(gdb) -var-list-children --all-values var7
^done,numchild="4",displayhint="map",children=[child={name="var7.[0]",exp="[0]",numchild="0",value="\"one\"",type="const std::basic_string<char, std::char_traits<char>, std::allocator<char> >",thread-id="1",displayhint="string",dynamic="1"},child={name="var7.[1]",exp="[1]",numchild="0",value="{...}",type="std::list<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >",thread-id="1",dynamic="1"},child={name="var7.[2]",exp="[2]",numchild="0",value="\"two\"",type="const std::basic_string<char, std::char_traits<char>, std::allocator<char> >",thread-id="1",displayhint="string",dynamic="1"},child={name="var7.[3]",exp="[3]",numchild="0",value="{...}",type="std::list<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > >",thread-id="1",dynamic="1"}],has_more="0"

I.e. KDevelop just shows what GDB says us to show.

I've tried MI command -enable-pretty-printing , it doesn't help at all, and at the same time plain CLI print works nicely.

My gdb version is 7.2-1.
Comment 5 Milian Wolff 2011-02-15 19:11:11 UTC
someone should report this as a GDB bug...
Comment 6 Milian Wolff 2011-11-20 22:42:59 UTC
created a bug report upstream: http://sourceware.org/bugzilla/show_bug.cgi?id=13419