My Journey to GJS’ Backtrace “full” Option

My outreachy internship has definitely taught me a lot of things including writing blog posts, reporting tasks, expressing myself and of course improving as a developer. When we developed a project timeline before submitting the final application weeks back, my mentor and I underestimated some of the issues because there were some hidden difficulties we only found out later.

Initially, my timeline was set to using the first week to understand the inner workings of the debugger, using week 2-4 on the backtrace full command, using week 5-7 to display the current line of the source code when displaying the current frame in the debugger and the task for week 8-13 were still to be decided upon by my mentor and I within the course of the internship.

After completing the 7th week of my internship, here are the things I have been able to accomplish

1. The first week of the internship was spent acquainting myself with how debugger tests are written using merge request 539(visit link for more details https://gitlab.gnome.org/GNOME/gjs/-/merge_requests/539) which was aimed at adding ‘$$’ as a shorthand to refer to the most recently printed value.I did a code review on this merge request in order to understand how it works. Also, I wrote a blog post introducing myself as an Outreachy intern at GNOME. Setting up my word press blog took me some time too since it was new to me. My mentor and I also drew up a plan on when we were to be having our weekly check-ins.
2. Week two started with me going through issue 208 (https://gitlab.gnome.org/GNOME/gjs/-/issues/208) which is adding the “full” option to the backtrace command. This week was spent studying the debugger API documentation (https://firefox-source-docs.mozilla.org/js/Debugger/) as well as asking questions where necessary.
3. The third week was used to start writing code to implement this functionality and writing my second blog post on ‘Everybody struggles’.
4. By the end of week 4, I had completed the implementation of the issue. My mentor reviewed the code and asked me to go on with writing tests.
5. After week one, I thought writing debugger tests were understood but week 5 proved me wrong. I had to ask my mentor to help me out by explaining everything again which he did. The holidays also had an impact on this week because some of my time was spent celebrating with family and friends.Also this week, I had to think about my audience and write a blog post to help new comers understand my project and community.
6. Week 6 I can say was my victory week because it is when I finally completed debugger tests for the backtrace “full” command. My mentor reviewed the code and we had a little challenge with version control. This helped me familiarize myself with some git commands (git checkout –file for discarding changes which you no longer want)and also see in practice how important it is to keep track of your project’s version.
7. Week 7 started with me asking my mentor advice on the next step which could be taken after this internship and also with us discussing issue 207 (https://gitlab.gnome.org/GNOME/gjs/-/issues/207) which is displaying the current line of source code in the debugger. By the end of this week I had a good understanding of the issue and subsequent weeks will be spent on completing this issue and also other issues that my mentor and I are still to decide on.

All of my activities during the past weeks have led me to accomplish one major thing which is adding the “full” option to the debugger’s backtrace command. It is my wish to use this as an opportunity to create awareness about how it works. I will be answering the questions what and why.

What is the “full” option of the backtrace command?

First of all, the backtrace 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 it’s 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 “backtrace full” or “bt full”.

Why the full option?

This is actually the first question I asked my mentor when this issue was assigned to me. To answer this question, he wrote a program which occasionally crashes when run on the debugger. The backtrace 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 we are about 2 weeks behind the initial time line and some reasons are because I underestimated the strength of the issues that had to be worked, did not take into account the few days to be used up for the Christmas holidays,the time spent on writing blog post and also the time spent on meetings with my mentor. The new timeline my mentor and I agreed on was using week 7, 8 and 9 to work on issue 207 and using week 10,11,12 and 13 on some issues we will discuss during our next meeting.