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