Debugging Mochitests with Visual Studio

Debugging an xpcshell test is far straightforward when compared to the more general mochitest. In the course of fixing a bug where change events weren’t being fired for a focused and blurred text input or textrea when the user switches focus, I encountered a situation where after my initial fixes, an extra change event was then fired. To hunt down the culprit code responsible for the redundant dispatch, the current docs on debugging mochitests weren’t particularly helpful to those of us working on windows machines with Visual Studio.  This technique is largely thanks to Josh Matthews and Mark Capella:

• Modify  testing/testsuite-targets.mk by deleting the autorun option under RUN_MOCHITEST.
• Afterwards, run the entire mochitest suite for the branch where the particular test you want to debug is located. Wait for the browser to open with the associated tests. In Visual Studio, go to Tools->Attach Process and select the firefox.exe process showing the loaded tests.  This should switch to the debugging view.
• Place an appropriate breakpoint in a relevant selection of the code that will most likely be triggered and then click on the link to the test that is to be debugged in the browser window.

Easy peasy lemon squeezy debugging

Building Firefox with pymake

Up until recently I had been doing local builds of Firefox for my patches with GNU make before switching over to pymake which is a bit faster. I had missed the doc strongly suggesting builds on Windows use pymake instead. Depending upon the files the patches being built touched, I could count on twiddling my thumbs from anywhere from an hour and 20 minutes  thereabout  to two at most. With pymake it takes just under an hour. It course it does help to have the latest hardware to speedup build time. More RAM wont hurt and neither would getting one’s hands on a core i7 machine be bad for starters.  Speaking of RAM, I had to run off to Best Buy and get some for my PC and  thereafter completely botched the installation. A workaround got them working, but then again I am careful with movements so as not to jar them loose out of the sockets.

At some point, I will have to upgrade my machine and eventually move to using Visual Studio 2011(in beta as of now). So this post is largely a note to myself in order to set up my development environment as fast as possible and correctly.

• Install the latest DirectX SDK available from here
• Grab and install the latest Mozilla-Build tools. Should be installed to the C:\ directory
• Within the mozilla-build directory, after selecting appropriate start-msvc##.bat file - where ## corresponds to the installed Visual Studio version, ensure all OK after running it.
• Console is by far one of best open-source utilities I have used.  It provides a windows Powershell-like interface by providing multiple tabs, text selection etc, which puts the default windows command terminal in the shade. It’s not a shell mind you! Often, I keep tabs opens each for a specific purpose: managing my mercurial queues, building code changes, one for redoing the final linking and finally another for running associated tests. After downloading and extracting,  copy the Console folder to C:\mozilla-build\msys.
• Next create a copy of the start-msvc##.bat and rename it to start-msvc##-Console.bat or any name to distinguish from the original batch file. This will be used often, so a shortcut of it to the desktop will prove most useful. Using notepad, edit the following lines:

from => cd "%USERPROFILE%" "%MOZILLABUILD%\msys\bin\bash" --login –i

     to => start /d "%USERPROFILE%" "" "%MOZILLABUILD%"\msys\Console\console.exe

• Obviously getting and unbundling the source and is well documented  here, so I wont go into too much detail other than pasting what I have in my current settings for both .mozconfig & hgrc files

.mozconfig

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=C:/mozillafirefox/trunk/src/ff-dbg
ac_add_options --disable-optimize
ac_add_options --enable-debug
ac_add_options --enable-tests
ac_add_options --enable-debug-symbol

hgrc

[paths]
default = http://hg.mozilla.org/mozilla-central
try = ssh://'mon.nom@somemail.xyz'@hg.mozilla.org/try/

[ui]
username = Mon nom <mon.nom@somemail.xyz>
editor = vim

[defaults]
qnew = -Ue

[extensions]
hgext.mq =
hgext.rebase =

[diff]
git = 1
showfunc = 1
unified = 8

• Since make.py-pymake- is nestled deep within src/build folder, trying to invoke it from anywhere within the src directory is unwieldy, ugly and error prone(learnt the hard way). For example running a  simple mochitest or xpcshell test brings it home. A simple set of aliases helps to reduce it. In c:\users\<username>, create a .profile file and enter the following into it:

alias pymake="python -OO build/pymake/make.py"
alias pyblink="pymake –C ff-dbg/toolkit && pymake –C ff-dbg/toolkit/library"

        The first alias is primarily for rebuilding the entire project from the src directory or a sub-directory as well as running tests. pyblink is mainly for performing the final linking in objdir folder to reflect code edits.

I guess the next step is to build with:  pymake –f client.mk