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)
- Check your
~/mozilla/.pluginsand remove plug-ins (symlinks) that you don't need. In my case, the Java 1.4.2 Plug-in caused the crash.
- If the above doesn't help, gathering more information related to the crash may provide a clue, as described in the following steps.
- Write a little wrapper for the
firefoxscript. Save it in
/usr/local/firefox/firefoxgor 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
ddddebugger frontend. You can then launch the executable by typing
runin the debugger console. In case of a crash (segmentation fault), you will see a stack trace which may contain interesting clues.
- Update your Selenium RC test script to reference the wrapper, e.g.
browser => "*firefox /usr/local/firefox/firefoxg".
- 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.
- 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
runin 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: