granata.enrico added a comment. Possibility number 3 (and the true reason why the check is there): if you stop at a place where the variable is not fully initialized/being torn down, and as a result, something is pointing back inside the list. For a list traversal, that is a deadly outcome.
This is (partially) the same reason why there's a cap on string summaries. It's fairly unlikely that a user will truly have a 3GB string (if they did, we might still want to cap it, but it's unlikely to begin with): an uninitialized string that claims to have a 3GB buffer. I think there are ways to make this code smarter. For instance, if you have to get node #10, you could only check for a loop up until node #10, and so on.. If you store the state of the loop-checker as you get out, you might get away without having to check the same nodes multiple times as you progress deeper into the list Drawback is that you would have already handed out at least some data by the time you find out the list is flawed. You can decide for yourself if that is a problem or not (the list might be partially valid, and returning some of the data is actually a good thing, maybe?) http://reviews.llvm.org/D13678 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
