[lldb-dev] Printing non-truncated stdlib collections?

[Dun Peal]

If it's trying to create 4 billion non-existing elements per vector,
there's probably no need to sample. It explains the lost time pretty well.

Let me know if you want me to file a bug. I'm encountering other issues,
for instance sometimes trying to `p some_name`, I get:

error: Couldn't materialize struct: size of variable some_name disagrees
with the ValueObject's size
Errored out in Execute, couldn't PrepareToExecuteJITExpression

Perhaps lldb simply isn't production ready for non-OSX platforms?


On Mon, Nov 4, 2013 at 2:14 PM, Enrico Granata <egranata at apple.com> wrote:

> Replies inlined
>
> Enrico Granata
> 📩 egranata@.com
> ☎️ 27683
>
> On Nov 4, 2013, at 1:48 PM, Dun Peal <dunpealer at gmail.com> 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 <egranata at apple.com>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 <dunpealer at gmail.com> 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 <gclayton at apple.com> 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 <dunpealer at gmail.com> 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
>>> > lldb-dev at cs.uiuc.edu
>>> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>>
>>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20131104/668c373f/attachment.html>