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:

• How to enable coredumps

$ 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.