[mythtv] Mythtv 0.23 RC Segfault in Mythfrontend

[Steve Berlo]

I did try uninstalling the i686 qt rpms, but I also followed Robert's advice
and cleaned up all of my old libmyth* files.  Once I recomplied, all was
well - no more segfault.

I would have to assume that this will work properly with the i686 RPM's
installed, but I have not tried it yet.  I have another mythtv system that
is an Intel 32-bit system.  This one only has i686 RPM's installed and I got
the same segfault on that system until I cleaned up the old libmyth files.
The backtrace shows the segfault specifically in the /usr/lib64 version of
the qt library, so I don't think it has anything to do with the i686 RPM's.

Anyway, maybe I'll go put those i686 RPM's back and recompile.  I would
imagine all will be OK....

Steve

On Tue, Mar 30, 2010 at 9:08 AM, R. G. Newbury <newbury at mandamus.org> wrote:

> On 03/30/2010 07:40 AM, tim at electronghost.co.uk wrote:
>
>>
>> On Mon, March 29, 2010 3:01 pm, R. G. Newbury wrote:
>>
>>> On 03/28/2010 07:18 PM, stuart wrote:
>>>
>>>> Steve Berlo wrote:
>>>>
>>>>> I just upgraded to Mythtv 0.23 and am getting a segfault when I
>>>>> attempt to watch any recordings or videos.
>>>>>
>>>>
>  Your uname -r says you are running x86_64 but you seem to be running a
>>> bunch of plain  i686 packages, especially qt.
>>>
>>> Here's my output of the same test, ALL X86_64:
>>>
>>> Your repo's are messed up. You might have to browse to a repo mirror,
>>> and force an install the correct architecture.
>>>
>>
>> Err, Fedora's multilib. You can install both 32 and 64-bit libraries. The
>> 32-bit libraries go in /usr/lib and the 64-bit libraries in /usr/lib64.
>> The
>> OP's list contains both sets. There's nothing wrong with that, or with his
>> repositories. If you tell yum to install a package without specifying the
>> architecture, it will normally install both 32 and 64-bit versions if both
>> are
>> available, since it doesn't know what sort of binary you will run.
>>
>> If there were anything wrong with that, myth wouldn't run at all, as the
>> runtime linker would fail to find the right libraries.
>>
>
> Well I agree that that makes some sort of sense, but I am not sure that the
> problem is not exactly what I surmise. Maybe he DOES need the x86_64
> libraries, in order to avoid that segfault. As to telling yum, that is done
> through the $ARCH variable. I don't get any i686 rpms in my installs.
>
> Herewith some output from my office desktop machine ( yes, of COURSE, I
> need mythtv at the office, for *testing purposes only*, don'cha know!). The
> laptop is the same, and I expect the mythbox is too.
>
> [root at tor1 ~]# uname -r
> 2.6.32.10-76.rc1.fc12.x86_64
> [root at tor1 ~]# rpm -qa | grep i686
>
> No output. NO i686 libs. (And FWIW, the only ix86 rpm is an adobe
> i386-noarch rpm)
>
> [root at tor1 ~]# service mythbackend status
> mythbackend (pid  18303) is running...
> [root at tor1 ~]# mythfrontend
> 2010-03-30 11:53:01.342 mythfrontend version: trunk [23850] www.mythtv.org
> 2010-03-30 11:53:01.355 Using runtime prefix = /usr/local
> 2010-03-30 11:53:01.355 Using configuration directory = /root/.mythtv
> 2010-03-30 11:53:02.829 Using localhost value of tor1.mandamus.org
> 2010-03-30 11:53:02.924 New DB connection, total: 1
> 2010-03-30 11:53:02.959 Connected to database 'mythconverg' at host:
> 192.168.1.99
> 2010-03-30 11:53:02.960 Closing DB connection named 'DBManager0'
> 2010-03-30 11:53:03.044 DPMS is active.
> 2010-03-30 11:53:03.083 Primary screen: 0.
> 2010-03-30 11:53:03.084 Connected to database 'mythconverg' at host:
> 192.168.1.99
> 2010-03-30 11:53:03.130 Using screen 0, 1920x1200 at 0,0
> 2010-03-30 11:53:03.188 Desktop video mode: 1920x1200 59.952 Hz
> 2010-03-30 11:53:03.456 MythUI Image Cache size set to 20971520 bytes
> 2010-03-30 11:53:03.481 Enabled verbose msgs:  important general
> 2010-03-30 11:53:03.516 Primary screen: 0.
> 2010-03-30 11:53:03.517 Using screen 0, 1920x1200 at 0,0
> .....
>
> Your last sentence may point to the problem however. From painful
> experience I have learned that the standard Fedora install does not properly
> set up the ld.so.conf file for those of us using trunk or compiling the
> code. This is my ld.so.conf, which places the lib64 directories ahead of
> their counterpart 32 bit versions. May be OP can test using this setup (and
> running ldconfig!)
>
> include ld.so.conf.d/*.conf
> /lib64
> /lib
> /usr/lib64
> /usr/lib
> /usr/local/lib64
> /usr/local/lib
> /usr/lib64/vdpau
> /usr/lib/codecs
> /usr/lib64/qt4
> /usr/lib64/qt-3.3/lib
> /usr/lib64/xorg/modules/drivers
> /usr/lib64/xorg/modules/extensions
> /usr/lib64/mysql
> /usr/lib64/flash-plugins
> /opt/google-earth
>
>
>
> Geoff
> --
>        Please let me know if anything I say offends you.
>         I may wish to offend you again in the future.
>
>         Tux says: "Be regular. Eat cron flakes."
> _______________________________________________
>  mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100331/05ab01a6/attachment.htm>