Solution for Selenium RC Firefox startup crash

Problem: A Selenium RC server under Linux starts a Firefox 3 (or 3.5) process, which then crashes immediately. A useless error dialog mentioning Gnome bug-buddy appears, the test script hangs. When started manually, the same version of Firefox works without flaw (including the Selenium IDE add-on).

Solution: (note: this was written for Selenium RC 1.0.1; you may wish to try the most current version (eg. 1.0.3) before troubleshooting)

1. Check your ~/mozilla/.plugins and remove plug-ins (symlinks) that you don't need. In my case, the Java 1.4.2 Plug-in caused the crash.
2. If the above doesn't help, gathering more information related to the crash may provide a clue, as described in the following steps.
3. Write a little wrapper for the firefox script. Save it in /usr/local/firefox/firefoxg or somewhere else:

   #!/bin/sh
   exec /usr/local/firefox/firefox -g $*
   

   If you start Firefox using this wrapper, you will notice that instead of the browser a debugger opens, in my case, the ddd debugger frontend. You can then launch the executable by typing run in the debugger console. In case of a crash (segmentation fault), you will see a stack trace which may contain interesting clues.
4. Update your Selenium RC test script to reference the wrapper, e.g. browser => "*firefox /usr/local/firefox/firefoxg".
5. In the shell where you launch the Selenium RC server, set the environment variable GNOME_DISABLE_CRASH_DIALOG=1, so that Gnome bug-buddy doesn't bother you on crash.
6. Go ahead and start the test script. The debugger will open. Actually, two instances of the debugger will open, the second one only after the first one is terminated. Type run in the debugger console to continue execution in each case. In my environment the first instance just crashed gdb. However, the second instance produced a backtrace which helped to put blame on the Java plug-in as shown below:

Subprocess post-installation script returned error exit status 1

Scenario: while installing a package in Debian, we get into the following situation:

debian:~# apt-get install bugzilla
Reading Package Lists... Done
Building Dependency Tree... Done
bugzilla is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 1272 not upgraded.
1 not fully installed or removed.
Need to get 0B of archives.
After unpacking 0B of additional disk space will be used.
Setting up bugzilla (2.22.1-2) ...
dbconfig-common: writing config to /etc/dbconfig-common/bugzilla.conf
dpkg: error processing bugzilla (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 bugzilla
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is yet another "observability" problem, as clearly too little information is provided to determine the problem's cause.

The correct way to proceed is to trace the execution of the failed post-installation script, but first we need to find out where it is and how it is called. Note that the apt-get install internally runs dpkg --install and, as we can learn from dpkg's man page, dpkg --configure. The post-installation script is invoked by dpkg --configure. To see how it is done, we use strace:

debian:~# ( strace -f dpkg --configure bugzilla 2>&1 ) \
| grep execve | grep post
[pid  6289] execve("/var/lib/dpkg/info/bugzilla.postinst",
["/var/lib/dpkg/info/bugzilla.post"..., "configure", "2.20.1-1"],
[/* 47 vars */] 
[pid  6289] execve("/usr/share/debconf/frontend",
["/usr/share/debconf/frontend", "/var/lib/dpkg/info/bugzilla.post"...,
"configure", "2.20.1-1"], [/* 45 vars */]) = 0
[pid  6310] execve("/var/lib/dpkg/info/bugzilla.postinst",
["/var/lib/dpkg/info/bugzilla.post"..., "configure", "2.20.1-1"],
[/* 46 vars */]) = 0

Based on the first logged execve, we try the following command:

/var/lib/dpkg/info/bugzilla.postinst configure 2.20.1-1; echo $?

and we see that it in fact reproduces the error reported by dpkg --configure. From here we can rely on generic shell script tracing or debugging techniques to determine the cause.

ModeLine ignored by xorg display driver

In the recent past, I used to switch screen resolutions in XFree/X.org by pressing the CTRL-ALT-minus or CTRL-ALT-plus keys. For each supported mode, there used to be a ModeLine entry in xorg.conf and those entries were referenced by the "Screen" section. As often happens when technology "advances", on my new Dell D830 notebook (using xorg 1:7.3+18 from Debian 'testing', GM965/GM960 graphics controller, 'intel' display driver), this tried and true method no longer works. The magic key combo is ignored altogether, as is adding ModeLines to xorg.conf. No warnings in /var/log/Xorg.0.log nor anywhere else are recorded, AFAICS. The standard xorg.conf seems almost empty, which in itself is a good thing (less configuration means less opportunity for mistakes). The bad thing, obviously, is that invalid or deprecated (?) configuration entries are silently skipped without a clue for the user about what is going on inside the black box, whether its behavior is normal or not, and which alternatives might be available. This is an example of what I like to call an "observability" problem. Sometimes a careless implementation is to blame, but such problems may also have their roots in software designers' inability to correctly foresee and specify the possible variance in implementations.

Fortunately, there is an easy solution to ignored ModeLines. xorg includes a program called xrandr, which can be used to test and programmatically set a resolution, as described in the Ubuntu Wiki article X/Config/Resolution. This seems to be a substitute for the traditional ModeLines in xorg.conf. Although the Wiki article mentions that xorg.conf can still be used for specifying resolutions, this is simply not the case in my setup.