Since I sometimes receive a bug report that is unusable for me or lacks important information, this short text should help people who aren't sure how to report a bug. Good, but longer and more general description of a bug reporting is How to Report Bugs Effectively.
Most important thing: Please report bugs!. Users are the best testers, especially in Open Source world.
It doesn't work is not enough
If you installed MOC and after typing ./mocp the programm crashes, it's not enough just say it crashes after startup. I really run my programs before releasing a new version, there must be something with your system or MOC config. You must at least report your operating system name and version, but in most cases it's still not enough.
First, make sure that the old version of MOC is not running, it's often a cause of an error at startup. It's easy to forget that you run MOC because no interface could be visible, only the server. Use ps ax | grep mocp to see if MOC is running.
Basic information
Basic information that are usefull in most cases:
- Your operating system name and version.
- MOC version (users often forget to say which version they are using).
- How did you get MOC - from sources or from a package.
Logs
MOC can create logs which are sometimes useful when reporting a bug. Just run MOC with --debug (or -D) option and two files will be created: mocp_server_log and mocp_server_log. Remember to shut down the server before doing this to get the server log (SHIFT-Q command or mocp -x).
You can include them with your bug report, but first compress them, preferably with bzip2 -9.
Logs could contain list of your files with tags and Internet radios URLs you played, remember this if you think it's sensitive information.
Simple things you can do to find the cause of a bug
- Try moving your ~/.moc directory elsewhere, there can be something in your configuration file or the playlist that causes the crash.
- The crash can be caused by one of your files, even you haven't played. Maybe there is a file which causes a crash when appears on the playlist? Try to find this file.
Backtrace
This is very useful after you get a segmentation fault or assertion failed. In such situation a core file is created. Some distributions disable dumping cores by default (like Slackware), type ulimit -c, if it displays 0, core files will not be create. In this case use ulimit -c 10000 to get core dumps in your session (in the terminal/console you used the ulimit command).
If you have a core file, you must have gdb to get a backtrace, this is an example:
daper@amd:~$ mocp
Running the server...
Trying JACK...
Trying ALSA...
Segmentation fault (core dumped)
daper@amd:~$ gdb mocp core
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
Core was generated by `./mocp'.
Program terminated with signal 11, Segmentation fault.
[ ...more messages from GDB... ]
(gdb) bt
#0 0x08063a70 in main_win_init (w=0xbf94f074,
layout_fmt=0x80b6130 "playlist:0,0,100%,100% directory:0,0,100%,100%")
at interface_elements.c:818
#1 0x08066c76 in validate_layouts () at interface_elements.c:1948
#2 0x08069aa0 in windows_init () at interface_elements.c:2942
#3 0x0805e694 in init_interface (sock=3, logging=0, args=0xbf94f428,
arg_num=0) at interface.c:1372
#4 0x080552a5 in start_moc (params=0xbf94f184, args=0xbf94f428, arg_num=0)
at main.c:188
#5 0x08055c95 in main (argc=1, argv=0xbf94f424) at main.c:548
In this example a core file was dumped, user issued gdb mocp core command and then in gdb used bt to get the backtrace. The text you should include in your bug report is after (gdb) bt.
