Bugs
Reporting bugs
If you find a bug in one of the ROX applications then please report it! There are several places where you can report problems:
- The rox-devel mailing list should be used if a bug needs to be tracked down (so lots of people can try to find it).
- There is also a news interface to the mailing lists, if you don't want to subscribe.
- The bug-tracking system can be used too, but please include your email address as we often need more information to solve the problem.
Information to include in a bug report
- Your operating system (eg, Debian Linux/testing)
- The program name and version ("Your program doesn't work" is too vague)
- Does the problem always happen, or just sometimes?
- Anything unusual about your system we should know?
- Did any errors get displayed? What were they? (copy them down exactly)
- Did you read the FAQ and search the Mailing Lists? (we're more sympathetic if you made an effort)
- For crashes and warnings, the more information you can provide the better. See below for instructions on collecting useful information
Please:
- Don't email a developer individually (except for security holes). Always use the Mailing Lists.
- Do send all the information in one go ("I've found a problem", "What is it?", "One of your programs doesn't work right", "Which one?", etc is very annoying)
How To Ask Questions The Smart Way contains good generic advice on reporting bugs. (They just provide advice on bug reports, they don't fix ROX bugs so don't ask them!)
Tip: When trying to fix a problem yourself, start by noting down the original error messages. Sometimes people try all sorts of crazy things (removing or upgrading libraries, moving files, etc) before finally writing to the mailing list for help, by which time they've forgotten what the original problem was!
(And there's nothing wrong with trying to fix things yourself; you'll learn plenty. But keep a log. It's hard to help you fix your system when you can't remember what you did!)
The following pages contain notes on some commonly-seen bugs, and instructions on how to collect useful information to send in bug reports.
Reporting bugs using Zero Install
If you are running your program using Zero Install then you can use the built-in bug reporting tool (in version 0.26 and later). Right-click over the application in ROX-Filer and choose Versions... from the menu:
Then right-click over the component with the bug (if unsure, just pick the one at the top, which is the main program):
Fill in the boxes. It will automatically fill in the bottom box with information about your system and which version of the program and libraries you're using. If the program prints errors when it fails, click on the 'Run it now and record the output' button to add them to the report too:
Common problems
Attempt to put segment in horiz list twice
This is caused by a bug in some old versions of librsvg (or similar) which fails to cope with some SVG images.
Either don't use SVG or upgrade to a fixed version of the library.
(anyone know which versions are affected?)
GtkTextSearchFlags is not an enum type
Various people have reported this error
** (0launch-gui:3347): WARNING **: `GtkTextSearchFlags' is not an enum type
This is not a bug in ROX; it affects all programs using PyGTK.
Upgrading your pygtk (or gnome-python) package should solve it. Also check that you don't have an old version of pygtk installed in /usr/local.
It appears that the bug was fixed in the PyGTK 2.2.x series.
I use blackbox/fluxbox and the root menus don't work properly anymore
These window managers don't support the Extended Window Manager Hints specification yet, although they hope to in future releases. In the meantime, turn on the 'Pass all backdrop mouse clicks to window manager' and 'Blackbox root menus hack' options in the Options box (Compatibility section).
ImportError: No module named gtk
Many of the ROX applications are written in Python. They require the Python PyGTK library in order to use the GTK toolkit (which provides windows, buttons and menus, etc, for programs). If it is not installed correctly, you may see:
ImportError: No module named gtk
PyGTK installation hints
Most Linux distributions include packages for PyGTK (the python-gtk2 package on Debian, for example), so check your distribution CDs for a copy first. Otherwise, the pygtk.org web-site has more information.
Warnings compiling pygtk: Warnings are printed for each C function that pygtk doesn't support. You can safely ignore these messages. Some modules (such as libgl and libglade) are only built if present. None of the ROX applications use them at present, so you can ignore these messages too! Finally, if you get an error about your version of automake, try just running make again...
Python2.2 or later must be the default version: if you must keep an older version as the default, you'll have to edit the first line of each application's AppRun file, changing 'python' to 'python2.2'.
PyGTK not found after installing: On some systems, you may need to use the --prefix argument to configure to ensure that pygtk gets installed to the same prefix as python (either /usr or /usr/local).
AttributeError: 'module' object has no attribute 'Window' PyGTK is not installed correctly. Try reinstalling. For more details, see this rox-users thread: http://thread.gmane.org/gmane.comp.desktop.rox.user/6672
For more help with PyGTK, please see the PyGTK mailing list or the PyGTK FAQ.
Testing your PyGTK installation
To test your installation, try running Python manually from a terminal emulator (xterm, gnome-terminal or similar) and importing gtk yourself, as follows:
$ python
Python 2.3.5 (#2, Jun 19 2005, 13:28:00)
[GCC 3.3.6 (Debian 1:3.3.6-6)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygtk; pygtk.require('2.0')
>>> import gtk
>>> gtk.Window
<type 'gtk.Window'>
>>>
If you get errors while doing this, then there is a problem with your installation that is not related to ROX; please ask your distribution for help.
Python programs segfault opening their options boxes
This is due to an expat version mismatch. See: 
Kerofin writes:
I've looked at the program that was dumping core and the sequence is this:
1) Program imports pygtk, which links in the GTK libraries
2) Program loads SVG image which links in librsvg.so which in turn links in /usr/local/lib/libexpat.so
3) Program imports pyexpat.
4) pyexpat calls XML_ErrorString, but as ld.so has already linked in XML_ErrorString from /usr/local/lib/libexpat.so it calls that version, not the one in pyexpat.so.
5) pyexpat looks up an error defined by the later version of expat it is expecting and gets a NULL pointer from the earlier version it has. It attempts to use it without checking (strlen) and dumps core.
Solution
Presumably, this can be fixed by upgrading to a later version of libexpat? If your system is affected, please add a comment giving the versions of Python and expat that are causing the problem, and whether upgrading helped.
ROX makes my memory card / USB drive read-only!
I have an .XLS file on a memory card, that when i open it via a left mouse click in ROX-Filer, opens in ooffice as read-only. However when I open it from the command line with "ooffice file.xls" it is not read-only.
There is a catch here though. If i open it with ROX-filer FIRST, before opening it command line, it will be read only. However if I open it with command line, and then ROX-Filer it is writable.
ROX never tries to make a filesystem read-only. However, if the kernel driver detects an error in the filesystem then it may remount it read-only to avoid further damage. Check the output of the dmesg command.
Threads:
ROX-Filer crashes with a BadWindow error during drag-and-drop operations
See:
ROX-Filer 2.3 and later contain a work-around for this GTK bug.
The pinboard only appears on one of my workspaces, or jumps in front of other windows!
Some older window managers don't fully support the Extended Window Manager Hints specification. In this case, you'll need to turn on the Override option in the Compatibility section of the Options box.
XFCE's root menu doesn't work anymore
The XFce root menu doesnt work with the pinboard, and 'Pass all backdrop mouse clicks to window manager' doesn't fix it.
XFce's root menu is part of the xfdesktop module, which creates a single large root window to set background image and create the root menu. ROX's pinboard also creates a large root window for desktop icons. These two compete.
However you can kill the xfdesktop and enable the ROX pinboard. When you do so the Xfce root menu will no longer work, but you will have desktop icons and the ROX-Filer menu by right clicking.
The Oroborus project has a Gtk+ 1.x application (on which xfdesktop is based) which doesn't create a large root window. It's called deskmenu, and provides a nice root menu without conflicting with the ROX pinboard.
Diagnosing problems
Keywords: crash, bug, segfault, debug
The more information you give, the easier it is for us to fix a bug. Please follow the instructions on this page to collect useful information about your problem.
Turn off themes
If you get memory leaks or crashes, and you are not using the default GTK theme, please try changing to the default theme and see if that helps. If so, it's probably a theme problem.
Problems when running something from ROX-Filer but not when running from an xterm
If a program behaves differently depending on whether it is run from an xterm or not, the most likely cause is that it relies on an environment variable that you set in your shell's login script. Check the output from running env in a filer window with running it in an xterm.
Using the GNU debugger
If you've got gdb installed then you can find out where the filer crashes by running it with the --debug option and the run -n command. When the filer crashes, use backtrace:
$ rox --debug (gdb) run -n ... Program received signal SIGSEGV, Segmentation fault. (gdb) backtrace useful stuff appears here (gdb) bt full even more verbose output appears here
The output produced by the backtrace command is very useful to us, so please include it in the bug report. Note, if the lines all start with ?? then the output is less useful (debugging information has been removed to save space). Please install from source and try again (but any debugging information is still better than none!).
If you've found the solution to your problem then you can submit a patch instead (see the Developers page).
If the filer crashes when you're not debugging and creates a core file, you can examine that with gdb too:
$ rox --debug core (gdb) backtrace useful stuff appears here
If the filer has hung (but not quit), replace 'core' with the process ID. System can show you this, or use pidof ROX-Filer:
$ pidof ROX-Filer 19536 $ rox --debug 19536 (gdb) backtrace useful stuff appears here
If you get Gtk-CRITICAL warning messages then you can force the filer to stop at the first one by starting it with:
$ rox --debug (gdb) run --g-fatal-warnings -n
Program received signal SIG35
Note: if you get "Program received signal SIG35, Real-time event 35.", this is
due to a directory changing rather than a bug. You can disable these events and then
c(ontinue) (the signal number may vary):
(gdb) handle SIG33 noprint nostop (gdb) c
System call trace
strace shows you exactly what a process is doing at the moment. It logs every call made between the process and the outside world.
To use strace (this works on any program), get the PID of the process (as explained above) and run:
$ strace -p PID useful stuff appears here
Valgrind
valgrind performs lots of extra checks while running a program. Valgrind is really good at spotting subtle errors that don't cause obvious failures normally.
To use valgrind, run the filer like this:
$ rox --valgrind -n useful stuff appears here
Performance problems
If things are just too slow, you need to run a profiler to find out why. strace (above) is quite good, especially with the -t option. Visualisation tools for strace logs are available; see this Profiling blog entry for an example.
sysprof monitors the whole system (so it will show you how much time was spent by the graphics system, the kernel, etc too) although it does require a kernel module.
If your problem is CPU-bound (rather than thrashing the disk or waiting for the network) then kcachegrind is superb.
Finding memory leaks
You can profile the filer's memory consumption using massif (part of valgrind). Run it like this:
$ rox --massif -n
Use it a bit to get the memory consumption up and then quit. You should get a .ps and a .txt file showing memory usage. That should tell you where the memory is being allocated.
It's also possible to get plain valgrind to report memory still in use at exit, but the output can be confusing because there are several caches (in GTK and ROX-Filer) which are intentionally not freed.
If you are having trouble understanding the results, put the txt file up on the web somewhere and post a link to the rox-devel mailing list.