[mythtv] mythbackend segfault in libQtCore release-0-22-fixes

[Daniel Kristjansson]

On Fri, 2009-12-18 at 14:22 +0000, Roger James wrote:
> I have upgraded to a recent (22974) checkout of release-0-22-fixes and I 
> am experiencing occasional crashes of mythbackend. I have attached the 
> syslog and backend log to the end of this message.
> 
> Has anyone else seen anything like this?
> 
> When the backend restarts it seems that the recording starts OK.
> 
> Why are three ASK_RECORDING requests made, is this significant?
> 
> Has anyone get any tips for debugging this?

Those logs don't really indicate anything terribly suspicious.
ASK_RECORDING messages are sent so that a frontend can ask the
user what to do if the backend wants to make a recording using
a recorder they are currently using to watch LiveTV, they are
ignored if a LiveTV session is not using that recorder and are
probably just a red herring.

The way to fix crashes is to get a backtrace that a developer
can look at. First you will need to either compile the debugging
version of MythTV, or add the debugging symbols package if you
use a pre-packaged MythTV; this will make the backtrace you
generate much more useful to the developer. My favorite 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 do this 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 /tmp/core.[rest_of_the_file_name]
>  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.

-- Daniel