Nice catch. You should be able to reproduce the bug like this:
(lldb) set append target.source-map 0 /tmp 1 /tmp 2 /tmp 3 /tmp 4
/tmp 5 /tmp 6 /tmp
(lldb) set show target.source-map
target.source-map (path-map) =
[0] "0" -> "/tmp"
[1] "1" -> "/tmp"
[2] "2" -> "/tmp"
[3] "3" -> "/tmp"
[4] "4" -> "/tmp"
[5] "5" -> "/tmp"
[6] "6" -> "/tmp"
(lldb) set remove target.source-map 1 3 5
(lldb) set show target.source-map
target.source-map (path-map) =
[0] "0" -> "/tmp"
[1] "1" -> "/tmp"
[2] "3" -> "/tmp"
[3] "4" -> "/tmp"
[4] "5" -> "/tmp"
[5] "6" -> "/tmp"
I.e., it removes the *third* element, instead of the *three* listed elements.
cheers,
pl
On 18 November 2016 at 21:07, Zachary Turner via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
> Also, I just noticed the loop only runs one time, so it appears equivalent
> to
>
> m_path_mappings.Remove(remove_indexes.size() - 1, m_notify_changes);
>
> which seems completely wrong
>
> On Fri, Nov 18, 2016 at 1:05 PM Zachary Turner <ztur...@google.com> wrote:
>>
>> In the switch / case handler for eVarSetOperationRemove, there is the
>> following code:
>>
>> if (num_remove_indexes) {
>> // Sort and then erase in reverse so indexes are always valid
>> std::sort(remove_indexes.begin(), remove_indexes.end());
>> for (size_t j = num_remove_indexes - 1; j < num_remove_indexes;
>> ++j) {
>> m_path_mappings.Remove(j, m_notify_changes);
>> }
>> }
>>
>> Should the line that calls Remove() not be like this:
>>
>> m_path_mappings.Remove(remove_indexes[j], m_notify_changes);
>>
>> ? What effect will this have on LLDB?
>
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
