[mythtv] Deciphering backtrace of loop/segfault

[Kevin Kuphal]

On Tue, Apr 6, 2010 at 12:02 PM, Robert McNamara
<robert.mcnamara at gmail.com> wrote:
> On Tue, Apr 6, 2010 at 9:57 AM, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>> On 04/06/2010 08:27 AM, Kevin Kuphal wrote:
>>>
>>> I have a friend who updated to 0.23-release tag from SVN and is
>>> experiencing the situation where his frontend segfaults when watching
>>> a recording.  I already had him clear out everything myth, distclean,
>>> recompile, etc. etc.  He compiled a debug copy of Myth and captured
>>> this backtrace.  Under gdb using the instructions on mythtv.org, the
>>> frontend doesn't segfault but sits at the "Please wait" screen.   Here
>>> is the results:
>>>
>>> http://pastebin.com/KXuaJGBY
>>>
>>> Any help would be greatly appreciated.
>>>
>>
>> Kevin,
>>
>> Though the backtrace doesn't tell me much (perhaps others can see more),
>> this sounds a lot like the the known race condition that "inspired"
>> http://svn.mythtv.org/trac/changeset/22350 as a workaround.  The real fix is
>> much more complex, and (TTBOMK), Mark K. will likely tackle it in the
>> libmythui-osd branch in order to allow the UI code and video code to be used
>> on the display at the same time.
>>
>> Does changing the 50ms sleep to some other value change the results?  If
>> not, I have another (more invasive) hack of a patch that changes timing more
>> significantly and can give you a copy to test as a system-specific
>> workaround.
>>
>> Mike
>
> This backtrace looks like someone has libmyth* junk left over from an
> old install.  did you have him rm /usr/lib/libmyth* and/or
> /usr/local/lib/libmyth*?

I can have him clean that stuff out (I thought we had) but I know that
when I do a "ldd mythfrontend" that it only shows it linking against
the 0.23 libraries in the /usr/lib64 folder per our ./configure

Kevin