<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>This one is not an issue. It's by design.</div><div><br></div><div>Solution: try</div><div><br></div><div>(lldb) frame variable vec[0]</div><div><br></div><div>Explanation: the expression command is using the compiler, clang, to generate code that runs in your inferior process. This requires the operator[] defined by your implementation of the STL to be around. If that is nowhere suitable to be find in the debug info (e.g. You never used it in your code) that expression will not be compilable since essentially it is as-if no vector::operator[] existed at all.</div><div>The way in which children in a vector are generated is totally unrelated to this. LLDB knows enough about the internals of the std::vector class to generate child variables as-if they were being accessed by indexing, but all without running code in your process. They are called "synthetic children" and are a debugger artifact essentially. Which is why sometimes we get it wrong: since we are not relying on anything but introspecting memory, we are more easily "fooled".</div><div>Our expression parser explicitly disallows such synthetic children for kicking in. Imagine if they did. Now your operator[] would not be invoked because the synthetic children feature would kick in and return a result. But what if you said</div><div><br></div><div>(lldb) expr vec[0] = 1</div><div><br></div><div>The synthetic children are a snapshot of memory so they don't know how to assign back to themselves. Hence why you don't want expressions to mix with synthetic children. It's a tricky business to get right.<br><br>Sent from the iPhone of<div><i>Enrico Granata</i> <egranata@🍎.com></div></div><div><br>On Nov 4, 2013, at 3:47 PM, Dun Peal <<a href="mailto:dunpealer@gmail.com">dunpealer@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">OK, I posted the original question of this thread as the following bug: <a href="http://llvm.org/bugs/show_bug.cgi?id=17805" style="font-family:arial">http://llvm.org/bugs/show_bug.cgi?id=17805</a></div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Another issue I just stumbled across:</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default"><div class="gmail_default"><font face="courier new, monospace">(lldb) p vec[0]</font></div><div class="gmail_default"><font face="courier new, monospace">error: call to a function 'std::vector<std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > >, std::allocator<std::vector<std::pair<int, int>, std::allocator<std::pair<int, int> > > > >::operator[](unsigned long)' ('_ZNSt6vectorIS_ISt4pairIiiESaIS1_EESaIS3_EEixEm') that is not present in the target</font></div>
<div class="gmail_default"><font face="courier new, monospace">error: The expression could not be prepared to run in the target</font></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 2:59 PM, Enrico Granata <span dir="ltr"><<a href="mailto:egranata@apple.com" target="_blank">egranata@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">The latter one I think is an expression parser issue.<div>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</div>
<div><br></div><div>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</div>
<div><br></div><div>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, ..</div><div><div class="im"><br><div>
<div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px"><div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px">
<div style="border-collapse:separate;border-spacing:0px"><span style="font-size:12px">Enrico Granata</span><br style="font-size:12px"><span style="font-size:12px">📩 egranata@</span><font color="#ff2600" style="font-size:12px"></font><span style="font-size:12px">.com</span><br style="font-size:12px">
<span style="font-size:12px">☎️ 27683</span></div></div></div>
</div>
<br></div><div><div class="h5"><div><div>On Nov 4, 2013, at 2:36 PM, Dun Peal <<a href="mailto:dunpealer@gmail.com" target="_blank">dunpealer@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">
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.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">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:</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default"><font face="courier new, monospace">error: Couldn't materialize struct: size of variable some_name disagrees with the ValueObject's size</font><br>
</div><div class="gmail_default">Errored out in Execute, couldn't PrepareToExecuteJITExpression<br></div><div class="gmail_default"><br></div><div class="gmail_default">Perhaps lldb simply isn't production ready for non-OSX platforms?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 2:14 PM, Enrico Granata <span dir="ltr"><<a href="mailto:egranata@apple.com" target="_blank">egranata@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Replies inlined</div><br><div>
<div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px"><div style="text-indent:0px;letter-spacing:normal;text-align:start;text-transform:none;white-space:normal;word-wrap:break-word;word-spacing:0px">
<div style="border-collapse:separate;border-spacing:0px"><span style="font-size:12px">Enrico Granata</span><br style="font-size:12px"><span style="font-size:12px">📩 egranata@</span><font color="#ff2600" style="font-size:12px"></font><span style="font-size:12px">.com</span><br style="font-size:12px">
<span style="font-size:12px">☎️ 27683</span></div></div></div>
</div>
<br><div><div><div>On Nov 4, 2013, at 1:48 PM, Dun Peal <<a href="mailto:dunpealer@gmail.com" target="_blank">dunpealer@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:'courier new',monospace">
In my case, it's a vector of vectors of pairs of ints, i.e. vector<vector<pair<int,int>>>.</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace">I'm not sure what "a sample of lldb taken while it's sitting there" means. Sorry, I'm an LLVM newbie.</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div></div></blockquote><div><br></div></div><div>If you are on OSX, it simply means typing <b>sample lldb</b> at a bash prompt :)</div><div>It will periodically look at the state of LLDB and generate a report of what is most likely taking up all that time</div>
<div><br></div><div>On Linux/Windows/.. I suppose there are equivalent facilities. Google is your friend. A process sample has nothing to do with LLVM specifically.</div><div><br><blockquote type="cite"><div dir="ltr">
<div class="gmail_default" style="font-family:'courier new',monospace">I have reproduced the problem with minimal code, posted below. Two interesting observations:</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default" style="font-family:'courier new',monospace">1) For some reason, lldb prints each vector<pair<int,int>> as:</div><div class="gmail_default" style="font-family:'courier new',monospace">
<br></div><div class="gmail_default"><div class="gmail_default"><font face="courier new, monospace"> [0] = size=4294967295 {</font></div><div class="gmail_default"><font face="courier new, monospace"> [0] = (first = 0, second = 1)</font></div>
<div class="gmail_default"><font face="courier new, monospace"> [1] = (first = 1, second = 2)</font></div><div class="gmail_default"><font face="courier new, monospace"> [2] = (first = 2, second = 3)</font></div><div class="gmail_default">
<font face="courier new, monospace"> [3] = (first = 3, second = 4)</font></div><div class="gmail_default"><font face="courier new, monospace"> ...</font></div><div class="gmail_default"><font face="courier new, monospace"> } </font></div>
<div style="font-family:'courier new',monospace"><br></div><div style="font-family:'courier new',monospace">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.</div>
<div style="font-family:'courier new',monospace"><br></div></div></div></blockquote><div><br></div></div><div>It looks like something is wrong with this data structure and we believe its size to be the large number</div>
<div>That value is not just a placeholder, it’s how many elements LLDB actually thinks are in the vector!</div><div>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</div>
<div>Why we end up with malformed data like that is an interesting question. I will try to repro</div><div><div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_default"><div style="font-family:'courier new',monospace">
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.</div>
<div style="font-family:'courier new',monospace"><br></div><div><div><font face="courier new, monospace">#include <iostream></font></div><div><font face="courier new, monospace">#include <vector></font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">using namespace std;</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">int main() {</font></div>
<div><font face="courier new, monospace"> vector<vector<pair<int,int> > > vec;</font></div><div><font face="courier new, monospace"> for (int i=0; i < 300; ++i) {</font></div><div><font face="courier new, monospace"> vector<pair<int,int> > v;</font></div>
<div><font face="courier new, monospace"> for (int j=0; j < 4; ++j) {</font></div><div><font face="courier new, monospace"> v.push_back(make_pair(i+j, i+j+1));</font></div><div><font face="courier new, monospace"> }</font></div>
<div><font face="courier new, monospace"> vec.push_back(v);</font></div><div><font face="courier new, monospace"> }</font></div><div><font face="courier new, monospace"> return 0; // to reproduce, put a breakpoint in this line, and `p vec`</font></div>
<div><font face="courier new, monospace">}</font></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 12:49 PM, Enrico Granata <span dir="ltr"><<a href="mailto:egranata@apple.com" target="_blank">egranata@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Yes please. Possibly with a sample of lldb taken while it's sitting there.</div><div>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?</div>
<div><br>Sent from the iPhone of<div><i>Enrico Granata</i> <egranata@🍎.com></div></div><div><div><br>On Nov 4, 2013, at 12:42 PM, Dun Peal <<a href="mailto:dunpealer@gmail.com" target="_blank">dunpealer@gmail.com</a>> wrote:<br>
<br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">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.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">The print only blocks for about 8 seconds when rendering the first 256 elements (i.e. without the settings change).</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">This is LLDB 3.4 from the LLVM aptitude repo, running on a high end Xubuntu Linux 13.04 developer workstation.</div>
<div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">This is obviously a major usability issue for me with LLDB. Should I file a bug for this?</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 4, 2013 at 10:05 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(lldb) settings show target.max-children-count<br>
target.max-children-count (int) = 256<br>
(lldb) settings set target.max-children-count 10000<br>
<br>
<br>
You can then add this line to your ~/.lldbinit file if you want the setting to always be increased.<br>
<div><br>
<br>
On Nov 3, 2013, at 7:57 PM, Dun Peal <<a href="mailto:dunpealer@gmail.com" target="_blank">dunpealer@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> When I do:<br>
><br>
> (lldb) p some_vector<br>
><br>
> It seems LLDB only actually prints the first 256 values. How do I get it to print the entire vector?<br>
><br>
> Thanks, D.<br>
</div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div>
</blockquote><blockquote type="cite"><span>_______________________________________________</span><br><span>lldb-dev mailing list</span><br><span><a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank">lldb-dev@cs.uiuc.edu</a></span><br>
<span><a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a></span><br></blockquote></div></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div></blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></blockquote></div><br></div>
</div></blockquote></body></html>