My Journey to GJS’ back-trace full option: Challenging but rewarding.

This is my third blog since the start of this internship, and I am getting pretty good at this 🙂

When Philip (my mentor) and I developed a project timeline for my final application, we underestimated some of the issues. The first week was reserved for understanding the inner workings of the debugger; weeks 2 – 4 for working on the back-trace full option, weeks 5 – 7 for displaying the current line of the source code when displaying the current frame in the debugger, and we were to think of what to work on during the final weeks of the internship.

As you can imagine, things didn’t go as planned. Much work has been done this last seven weeks, but certainly not at the pace I had expected. My mentor thinks my pace is fine, though, and he advised that I focus on the small wins.

Here is how much we have been able to accomplish so far:

1. I used my first week getting acquainted with how debugger tests are written. I reviewed this merge request : https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/539 aimed at adding ‘$$’ as a shorthand to refer to the most recently printed value, to help me better understand how it works. Also, Philip and I picked a suitable time for our check-ins.
2. By the start of the second week, I started working on adding the full option to the back-trace command. You can check out this issue here: https://gitlab.gnome.org/GNOME/gjs/-/issues/208. I also spent some time studying the debugger API documentation at https://firefox-source-docs.mozilla.org/js/Debugger/, asking questions when necessary.
3. At the end of the fourth week, I had completed the implementation of the issue. It was reviewed, and I had to write the test, which I did in week 5.
4. The sixth week, I can say, was victory week. The issue was complete and all the tests passed. I had some challenges with version control but finally worked around them. The work was merged and everyone was happy 🙂

Now, let’s throw more light on the full option, what it is and why it is necessary.

What is the “full” option of the back-trace command?

Firstly, the back-trace command gives you a summary of how your program got to where it is. It shows one line per frame, for many frames, starting with the currently executing frame (frame 0), followed by its caller (frame 1), and up the stack. Now, the full option prints out the values of all local variables for each stack frame, hence adding this option improves on the user experience of the debugger. After running the debugger on a file, you can see the full option in action by entering “back-trace full” or “bt full”.

Why the full option?

This is the first question I asked my mentor when this issue was assigned to me. To answer this question, he wrote a program which occasionally crashed when run on the debugger. The back-trace full is particularly good for getting stack traces from the user. If you are the developer, it’s not so hard to print the variables you need, because you will often already know which ones you need, but if a user has the crash, then maybe you can get them to run the program in the debugger, but it’s very time-consuming to go back and forth telling them “OK, now type print x”, “now type print y” when you can just get all the information at once by telling them to type “bt full”.

After 8 weeks of this internship, it is clear that nothing good comes easy. Getting the full option to work took some time and effort, but it was definitely worth it. I’m excited to see what I’ll be working on next.