The latter one I think is an expression parser issue. It should be fixed in ToT already, but I CC’ed on this email Sean Callanan who works on this part of LLDB and might have more insights for you
I tried to reproduce your issue on OSX Mavericks, but in spite of me trying to print ~11.000 pairs (I raised your 300 to 900 and put 12 pairs in each sub-vectors instead of 4), it took about 5 seconds to print everything If you do file a bug, which you totally should, more details on your environment might be interesting: OS, compiler, standard library, revision of LLDB, .. Enrico Granata 📩 egranata@.com ☎️ 27683 On Nov 4, 2013, at 2:36 PM, Dun Peal <[email protected]> wrote: > 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 <[email protected]> wrote: > 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
