Replies inlined

Enrico Granata
📩 egranata@.com
☎️ 27683

On Nov 4, 2013, at 1:48 PM, Dun Peal <[email protected]> wrote:

> In my case, it's a vector of vectors of pairs of ints, i.e. 
> vector<vector<pair<int,int>>>.
> 
> I'm not sure what "a sample of lldb taken while it's sitting there" means. 
> Sorry, I'm an LLVM newbie.
> 

If you are on OSX, it simply means typing sample lldb at a bash prompt :)
It will periodically look at the state of LLDB and generate a report of what is 
most likely taking up all that time

On Linux/Windows/.. I suppose there are equivalent facilities. Google is your 
friend. A process sample has nothing to do with LLVM specifically.

> I have reproduced the problem with minimal code, posted below. Two 
> interesting observations:
> 
> 1) For some reason, lldb prints each vector<pair<int,int>> as:
> 
>   [0] = size=4294967295 {
>     [0] = (first = 0, second = 1)
>     [1] = (first = 1, second = 2)
>     [2] = (first = 2, second = 3)
>     [3] = (first = 3, second = 4)
>     ...
>   } 
> 
> Since each of those vectors is exactly 4 pairs, it is printed in its 
> entirety, so I'm not sure why there's an ellipsis there.
> 

It looks like something is wrong with this data structure and we believe its 
size to be the large number
That value is not just a placeholder, it’s how many elements LLDB actually 
thinks are in the vector!
Most likely we end up realizing those are not valid and so we omit printing 
them, but we still believe they exist, and since you likely asked to see all of 
them, we are trying to create 4 billion elements and failing. Here your 300 
seconds
Why we end up with malformed data like that is an interesting question. I will 
try to repro

> 2) The times I quoted above are surprisingly preserved with this sample code. 
> For example, printing the first 256 elements is still about 8 seconds. 
> Printing all 300 elements, which is only about 20% more, takes 300 seconds, 
> i.e. almost x40 the time!  Curious.
> 
> #include <iostream>
> #include <vector>
> 
> using namespace std;
> 
> int main() {
>     vector<vector<pair<int,int> > > vec;
>     for (int i=0; i < 300; ++i) {
>         vector<pair<int,int> > v;
>         for (int j=0; j < 4; ++j) {
>             v.push_back(make_pair(i+j, i+j+1));
>         }
>         vec.push_back(v);
>     }
>     return 0;  // to reproduce, put a breakpoint in this line, and `p vec`
> }
> 
> 
> On Mon, Nov 4, 2013 at 12:49 PM, Enrico Granata <[email protected]> wrote:
> Yes please. Possibly with a sample of lldb taken while it's sitting there.
> From your email, it sounds like the repro case is just a vector of pairs of 
> int and int, with about 400 elements. Is that all?
> 
> Sent from the iPhone of
> Enrico Granata <egranata@🍎.com>
> 
> On Nov 4, 2013, at 12:42 PM, Dun Peal <[email protected]> wrote:
> 
>> Thanks!  This works, though surprisingly slow; I just printed a 
>> vector<vector<pair<int,int>>> of 384 elements, and it blocked for about 390 
>> seconds (6:30 minutes!) before rendering.
>> 
>> The print only blocks for about 8 seconds when rendering the first 256 
>> elements (i.e. without the settings change).
>> 
>> This is LLDB 3.4 from the LLVM aptitude repo, running on a high end Xubuntu 
>> Linux 13.04 developer workstation.
>> 
>> This is obviously a major usability issue for me with LLDB. Should I file a 
>> bug for this?
>> 
>> 
>> On Mon, Nov 4, 2013 at 10:05 AM, Greg Clayton <[email protected]> wrote:
>> (lldb) settings show target.max-children-count
>> target.max-children-count (int) = 256
>> (lldb) settings set target.max-children-count 10000
>> 
>> 
>> You can then add this line to your ~/.lldbinit file if you want the setting 
>> to always be increased.
>> 
>> 
>> On Nov 3, 2013, at 7:57 PM, Dun Peal <[email protected]> wrote:
>> 
>> > Hi,
>> >
>> > When I do:
>> >
>> > (lldb) p some_vector
>> >
>> > It seems LLDB only actually prints the first 256 values. How do I get it 
>> > to print the entire vector?
>> >
>> > Thanks, D.
>> > _______________________________________________
>> > lldb-dev mailing list
>> > [email protected]
>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>> 
>> 
>> _______________________________________________
>> lldb-dev mailing list
>> [email protected]
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
> 

_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

Reply via email to