For this side quest, I had a selection of bugs to choose from for an attempt to fix it. The bug I chose had to deal with {} characters while searching in a folders. I chose this over the other bugs because I was able to replicate this error, and felt I had a good chance to tackle this bug. The other bug I looked at had to do with markdown reference not linking properly when there was a forward slash escape sequence ( \ ). I was not able to replicate this error in my VSCode, so I settled on the folder searching bug.
The {} character bug was originally tested under OS Version: Mac OS X El Capitan 10.11.6, but I was able to replicate it under my Windows 7 Home Premium 64-bit (6.1, Build 7601) machine.
What is this bug?
This bug is caused by having {} characters as part of a directory name. To test this bug, I created two directories named hello and {hello}. Within the directories, I had a text file named “hello.txt” and “hello2.txt” which contained the words “hello”. Below is a screenshot of the file system I used to test the bug:
To test the bug, my first test case involved only searching for “hello” inside any file. As you can see in the screenshot below, a basic hello search will find both files with the “hello” text.
My next test is another hello search, but with an additional parameter of hello at the files to include. This test results eliminates ./{hello}/hello.txt from the previous results and we are only left with ./hello/hello2.txt.
My last test is a hello search with {hello} at the files to include field. Logically, the expected search result is one file, with ./{hello}/hello.txt being found. However, due to the bug, ./hello/hello2.txt is found instead.
Bug is found, but what is next?
From the last screenshot above, I surmised that under the files to include field, only hello is being passed between the method calls instead of {hello}. To test this premise, the first thing I did was open up the Developer Tools. The keyboard shortcut is Ctrl + Shift + I. With the Developer Tools opened, I can then track the elements being modified when a search is initiated.
From the tools, I can tell which elements are modified when I perform a search. The tool also grants access to the debugger, allowing for break point insertions into the code itself.
From class, the professor searched for the keyword “ripgrep” on the VSCode library on GitHub, and found a file of interest called ripgrepsearch.ts. However, I also noticed a file called search.ts within the same directory that appeared of interest to me, and decided to look into that file instead.
Without not much to go on, I inserted a break point to one of the first service calls inside search.ts, and decided to watch over an attribute called “includePattern”. The goal was to see when this attribute changed from {hello} to hello. From the screenshot below, it shows that the includePattern starts off perfectly fine as {hello}.
One of the things I noticed was that VSCode was treating { and } characters as word separators. I am not sure if this will have an impact on the includePattern, but this seemed like a probable cause for the bug as well.
To narrow down the source of the bug, I stepped from my first breakpoint at line 273 of searchService.ts, to the statement that populated the faulty search results. This narrowed the range of my bug hunt. Below is a screenshot of the code the updates the search results onto the screen:
I now have a specific range to search for the bug. Unfortunately, after hours of searching, I could only narrow the search between the line of code at searchModel.ts and the update result from earlier. Below is the furthest point I managed to narrow down before I could no longer make sense of the code.
As highlighted, the includePattern is still {hello} at that point, and the query seems to be correct at that point. After this point, the code jumped around to notifySuccess() calls, before reaching the update search results call.
Conclusion:
This was a good experience for me in bug tracking. It exposed me not only to the Developer Tools built into VSCode, but I also used Github’s search functions to help narrow the scope of my searches. I was confident that by using the debugger to step line by line, I’d eventually find the code which caused the bug, but it is apparent that there is more to bug tracking than that.
Hopefully in the future, as my debugging knowledge improves, I’d be able to go over hurdles such as the one I encounter today.
Owen's Adventures 