Difference between revisions of "Debugging"

From MythTV Official Wiki
Jump to: navigation, search
m (Debugging package-based installs: Spell-check didn't find "second", a mis-spelling of "section")
m (Debugging with Ubuntu packages: No need for "svn" when describing snapshots, now.)
Line 32: Line 32:
 
== Debugging with Ubuntu packages ==
 
== Debugging with Ubuntu packages ==
  
Although it's possible to debug with the packages in the Ubuntu archive, it is first recommended that you enable the Mythbuntu autobuilds packages and make sure that the issue is occurring with them.  These are built from the latest upstream svn snapshots of either -fixes or -trunk, whichever you choose.  You can enable autobuilds at http://mythbuntu.org/auto-builds .
+
Although it's possible to debug with the packages in the Ubuntu archive, it is first recommended that you enable the Mythbuntu autobuilds packages and make sure that the issue is occurring with them.  These are built from the latest upstream snapshots of either -fixes or -trunk, whichever you choose.  You can enable autobuilds at http://mythbuntu.org/auto-builds .
  
 
If you can still reproduce the problem with the latest autobuilds packages, please follow these steps to grab everything necessary for a bug report:
 
If you can still reproduce the problem with the latest autobuilds packages, please follow these steps to grab everything necessary for a bug report:
Line 92: Line 92:
  
 
Locally a trace will be performed and uploaded to the bug.
 
Locally a trace will be performed and uploaded to the bug.
 
  
 
== Debugging with Gentoo ebuilds ==
 
== Debugging with Gentoo ebuilds ==

Revision as of 22:49, 26 December 2010

If any of your MythTV programs crash (segfault), you must generate a proper backtrace before submitting a new bug report. Please also see the Ticket HOWTO for more information before submitting a bug report.


Debugging source-based installs

Section 22.2 of the MythTV Documentation, linked from the MythTV website provides details of debugging source-based installs.

Note, also, that in addition to --compile-type=debug, the MythTV configure script now supports an option, --compile-type=profile. In many cases, a profile build will be acceptable for creating backtraces. The main difference between the debug and profile builds is that the debug build disables optimizations. Therefore, a debug build may perform significantly worse than a profile build. If you need to run MythTV under gdb for a long time, it may be worthwhile to run a profile build. If, however, a developer asks you to re-create the backtrace using a debug build, please do so without argument as some portions of the code can only be reliably debugged with a debug build. However, if your system is sufficiently powerful to run a debug build, you may want to start with that so you can be certain the backtrace will be useful.


Debugging package-based installs

Note that rather than recompiling to perform the debugging, you may be able to use "debug" packages provided by your packagers. Debug packages simply install the debugging symbols for the already-installed packages you're using, meaning you do not have to uninstall or reinstall MythTV. Often using the debug packages requires enabling a special repo that contains the debug packages.

Once the debug packages have been obtained, you can generally create a backtrace as described, above, for source-based installs, skipping the section on compiling and installing and, instead, only performing the actions described for using gdb. Some distributions provide other tools that may help create and/or submit backtraces and associated logging information. See below for distribution-specific details.


Debugging with ATrpms packages

yum --enablerepo=atrpms-debuginfo install mythtv-debuginfo

or for all other environments eg testing/bleeding etc..

yum --enablerepo=atrpms\*-debuginfo install mythtv-debuginfo


Debugging with RPM Fusion packages

yum --enablerepo=\*-debuginfo install mythtv-debuginfo

Debugging with Ubuntu packages

Although it's possible to debug with the packages in the Ubuntu archive, it is first recommended that you enable the Mythbuntu autobuilds packages and make sure that the issue is occurring with them. These are built from the latest upstream snapshots of either -fixes or -trunk, whichever you choose. You can enable autobuilds at http://mythbuntu.org/auto-builds .

If you can still reproduce the problem with the latest autobuilds packages, please follow these steps to grab everything necessary for a bug report:

Basic Backtrace

For most people, this is all that needs to be followed.

1) Install the 'mythtv-dbg' and/or 'mythplugins-dbg' packages to add debugging symbols to your system.

# sudo apt-get install mythtv-dbg mythplugins-dbg

Note: if you are using the auto-build packages, make sure your system is up to date. Run the following before installing mythtv-dbg and mythplugins-dbg. It's also ok to run this command after the above installation command if you get an error about mismatched versions.

# sudo apt-get upgrade

If you have problems with this and want to back out you can do the following.

# sudo apt-get remove mythtv-dbg mythplugins-dbg
# sudo apt-get --reinstall install mythtv-frontend mythtv-backend

2) Modify /etc/default/apport to set "enabled" to 1

3) Start the apport service. "sudo start apport"

4) When your crash happens, it will ask you to submit a bug report. Submit the full report. You'll need a launchpad account for this.

Advanced Retrace

If you are asked to rerun the trace with symbols for the dependencies, you can follow these directions. This is *not* necessary for most people. Take note of the bug number you just above filed, you'll need it here.

1) Install the apport-retrace tool so you can locally run a backtrace on a core dump.

# sudo apt-get install apport-retrace

2) Enable the debug debs repository.

# echo "deb http://ddebs.ubuntu.com $(lsb_release -cs)-updates main restricted universe multiverse
# deb http://ddebs.ubuntu.com $(lsb_release -cs)-security main restricted universe multiverse
# deb http://ddebs.ubuntu.com $(lsb_release -cs) main restricted universe multiverse" |
# sudo tee -a /etc/apt/sources.list.d/ddebs.list

3) Grab the key for the debug debs repository

# gpg --keyserver keyserver.ubuntu.com --recv-key 428D7C01 5E0577F2
# gpg --check-sigs 428D7C01 # signed by key of Martin Pitt
# gpg -o - --export 428D7C01 | sudo apt-key add -

4) Update your package lists

# sudo apt-get update

5) Run the apport-retrace tool.

# sudo apport-retrace --auth -v BUGNUMBER

6) Your web browser should open up. You'll need to give the apport-collect "Full Access".

7) Return to apport-retrace invokation and press Enter.

Locally a trace will be performed and uploaded to the bug.

Debugging with Gentoo ebuilds

Rebuild with debugging symbols intact

for package in `equery l -i myth | awk "{print $3}" | tail -n+2`
do
 USE="debug" && FEATURES="splitdebug" && emerge --oneshot =$package
done

Using core files

Important.png Note: You still need to have installed a debug build or debug packages to create a useful backtrace with a core file.

One way to get backtraces for the backend is to dump core on crashes and then use gdb mythbackend name_of_core_file, this allows you to restart the backend on crashes and still get a backtrace at your leisure. To ensure core files are created when mythbackend crashes, add these three lines to your mythbackend startup script:

ulimit -c unlimited
echo 1 > /proc/sys/kernel/core_uses_pid
echo "/tmp/core.%t.%u.%p.%e" > /proc/sys/kernel/core_pattern

The first allows core files to be used, the second allows the %p in the third line, and the third line creates individual core dumps for each program crash in tmp so they are easy to locate, and have the program that crashed and the time it crashed along with other useful information right in the name.

To finally produce the backtrace run:

$ sudo gdb mythbackend -c /tmp/core.[rest_of_the_file_name] 2>&1 | tee mythtv_backtrace.txt
set pagination off
thread apply all bt
quit

Unless there was memory overwriting going on or there was a serious hardware failure, the output will tell us exactly what line of code the backend crashed on, and what other threads were doing at the time.