Debugging and editing tools

Transcript of the Debugging and Tools talk given at Samsung

• lars: we want to talk about github, the tools we use on servo, and how to debug and profile servo. one of the things we want to talk about first is not being shy on github. we are always hapy to respond; to request review, use "r? @username" which is short for review. please ask again if we don't respond within 24 hours, we want to help but sometimes get overwhelmed. on IRC you can always ask if someone is available to talk with "username: ping"; if they are available, respond with "pong", but it's not necessary if they're already active. if you want feedback on your changes before you create a pull request, you can commit to your local repository and put a link in the corresponding issue. we are happy to provide feedback while you're waiting for approval.
• lars: moving on to build issues - if not profiling, we recommend passing these flags to the configure script: "../configure --disable-optimize --enable-debug". Servo will build ~4x faster with optimizations off, and you can use gdb to get useful information while debugging. You can perform individual builds without optimizations with "make CFG_DISABLE_OPTIMIZE=1".
• lars: about configure: if you have changes in submodules and reconfigure, it will throw away your changes. *pcwalton: if you run configure with --disable-mange-submodules this does not happen.
• kmc: if you have a local commit in a submodule, configure will lose it, but you can find it again with "git reflog". feel free to ask questions about git; the way we use it is complicated.
• pcwalton: we want to move from submodules to rustpkg, but that won't be for several months.
• lars: sometimes builds fail in unexpected ways. run "make VERBOSE=1", which will print the actual command lines for rustc. "make clean" deletes everything except for rust and llvm, "make clean-servo" will delete the servo crates, but not the submodules, so rebuilding is much faster.
• jack: there are make targets for "clean-[submodule]" like "clean-rust-layers".
• lars: multiple build directories are possible, since there is nothing special about the servo/build directory.
• kmc: run "gdb --args ./servo ../src/test/html"; --args passes are subsequent arguments to servo instead of gdb. gdb does not catch rust task failure by default, but you can break on rust_begin_unwind, which is called on every task failure. shows the failure message and the line number of failure, and can see a full backtrace with "bt" or "backtrace". the first frames are in the runtime, but eventually can see frames starting with servo crates. use "frame #" to visit the failing stack frame. this should be the line containing the fail! call, but there is a rust bug that makes this show the wrong line number and file right now. the "task failed" message shows the correct information. "list" shows the surrounding code for any frame, and "up" and "down" move up and down the stack backtrace.
• kmc: note that gdb information works best with the "-Z extra-debug-info" argument to rustc.
• kmc: a segfault is nice to debug, since no breakpoints are necessary, and it shows the faulting line. we can look at local variables with "info locals", but enum types can be confusing (they look like unions when debugging C/C++ code).
• pradeep: do we need a recent gdb?
• kmc: should not, but need to build servo with --enable-debug. can also configure with --disable-optimize-cxx, which disables optimizations in C code (useful for debugging C code).
• kmc: valgrind is useful for debugging memory corruption. no demo, since it's a bit complex, but there is information on the wiki at https://github.com/mozilla/servo/wiki/Debugging . please ask questions if you want to know more.
• kmc: git has the reflog feature, which is history of every change you make. every checkout, every commit, every rebase. if I amend a commit, it looks like it changes the original one. it really adds a new one, so you can go into the reflog and interact with the old, un-amended commit (for example, git show old-sha). if you are developing on a mac (especially on 10.9) you need a particular version of gdb, and we can help you set that up.
• ryanc: if I have several commits and want to merge them, how can I do that?
• kmc: "git log" shows that I have multiple commits (two in this case). if I use "git rebase -i origin/master" or "git rebase -i HEAD~~" to rebase starting from a named commit (HEAD refers to commit that is checked out, and ~~ means "two revisions behind"; "man git-rev-parse" explains ways of naming commits). this opens my editor, showing one line for every commit. if I reorder them, it changes the order in the history (from top to bottom).
• jack: sometimes when I work on a project I make commits fixing unrelated bugs. I like to move them to the top before making a pull request.
• kmc: if I change "pick" to "fixup", it merges the commit with its parent and uses the parent's commit message. if I make a mistake, I can look in the reflog for the commit before the rebase, then go back in time with "git reset --hard sha" which destroys all other commits since then. if I want to merge the commits and change the commit message this time, using "squash" instead of "fixup".
• jack: if there are commits you don't want to include, you can just delete the line.
• kmc: rebase is powerful; if you reorder commits, you can have merge failures. "git status" shows the files with conflicts, and "git diff" shows the conflicts. resolve them like normal merge failures. there are emacs and vim modes for fixing conflicts, but you can just use a regular editor as well. when you resolve the conflict, use "git add path/to/file", and then you continue the rebase with "git rebase --continue". repeat the process for each conflict until the rebase is complete.
• kmc: if you have pushed a commit, and then you rebase it, you can cause "non-fast-forward" commits that can break anyone who is using your branch. if it's just your own personal branch for review, it's not a problem, but you should not rebase and push to official mozilla repositories that everyone uses.
• kmc: if you make multiple changes to a file, "git add path/to/file" stages (prepares to commii) all of them. if you use "git add path/to/file -p", it shows a prompt where you can select which changes to stage. if you commit one change and not the other, git diff will show the change that was not staged.
• kmc: I made a wrapper script around gdb call rust-backtrace (see wiki: https://github.com/mozilla/servo/wiki/Debugging ) which sets the rust_begin_unwind breakpoint automatically, and prints the backtrace automatically before quitting.
• hyunjune: I could not find the main function in servo, why?
• kmc: the code that sets up glfw for servo has to run on the OS main thread, so instead of "fn main" we define "fn start" and tell the compiler to call start before setting up the rust runtime. in servo.rc, it does some process, then calls "rt::run_on_main_thread" to set up a runtime that is associated with the main thread.
• pradeep: "perf record -g fp ./servo ../src/test/html/about-mozilla.html". not working for demo, though.
• pradeep: here is an on-the-fly syntax checker for emacs. building can be slow, so this runs rustc in syntax check mode so it is very fast. It underlines the thing that is wrong, and the minibuffer shows the precise error when the cursor is over the text with an error. This mode is called "flycheck" mode, need to set it up with the servo rustc build. Can install it from the emacs package manager - flymake and flymake-rust.
• kmc: please add the instructions for using flymake and autocompletion (and tags) to the wiki!
• jack: how do you keep the tags up to date?
• pradeep: manually.