Mailing List Archive: mythtv 0.25 segmentation faults with mythpreviewgen and mythmetadatalookup

mythtv 0.25 segmentation faults with mythpreviewgen and mythmetadatalookup

Apr 15, 2012, 2:51 PM

Post #1 of 4 (1926 views)

Hi all,

have just upgraded a F16 mythtv 0.24 system (combined backend/frontend) to
0.24 via installing the 25-284 and then 0.25-285 rpms - thanks for
providing these Axel!

most things (recording and frontend) seem to be working fine but the
backend log contains a number of:
2012-04-15 22:22:19.546395 E [1764/27581] HttpServer200
previewgenerator.cpp:254 (Run) - Preview: Encountered problems running
'/usr/bin/mythpreviewgen --size 0x0 --chanid 2007 --starttime
20120415214700 --outfile "/media/recordings/2007_20120415214700.mpg.png"
--verbose general --logpath /var/log/mythtv --loglevel info --quiet' (140)

and running mythpreviewgen (and mythmetadatalookup) with any paramaters
just seems to result in seg fault:
[mythtv@Beaker ~]$ mythpreviewgen
Segmentation fault
[mythtv@Beaker ~]$ mythmetadatalookup
Segmentation fault

Can anyone suggest any steps to help diagnose this issue (or is this a
question for the mythtv users list)?

Additional info:
a few days prior to upgrading to 0.25 I fully working 0.24 (0.24-280) to
0.24.2-281 and after this update all mythprograms just seg faulted
(mythbackend, mythfrontend and mythtv-setup). It is very possible yum would
have updated other things at the same time but yum.log does not stretch
back this far - so I have not been able to establish what this would have
been.

any help greatly appreciated!

[mythtv@Beaker ~]$ rpm -qa|grep myth
libmythprotoserver-0.25_0-0.25-285.fc16.i686
libmythswscale0-0.25-285.fc16.i686
mythtv-0.25-285.fc16.i686
mythtv-frontend-0.25-285.fc16.i686
mythes-1.2.1-3.fc15.i686
libmythhdhomerun-0.25_0-0.25-285.fc16.i686
mythtv-backend-0.25-285.fc16.i686
mythtv-themes-0.25-285.fc16.i686
libmythavformat52-0.25-285.fc16.i686
mythnetvision-0.25-285.fc16.i686
mythtv-setup-0.25-285.fc16.i686
libmythavutil50-0.25-285.fc16.i686
libmythtv-0.25_0-0.25-285.fc16.i686
mythgame-0.25-285.fc16.i686
libmythbase-0.25_0-0.25-285.fc16.i686
mythweb-0.25-273.noarch
mythgallery-0.25-285.fc16.i686
libmythui-0.25_0-0.25-285.fc16.i686
mythmusic-0.25-285.fc16.i686
libmythavcodec52-0.25-285.fc16.i686
libmythmetadata-0.25_0-0.25-285.fc16.i686
mytharchive-0.25-285.fc16.i686
libmythservicecontracts-0.25_0-0.25-285.fc16.i686
mythtv-docs-0.25-285.fc16.i686
mythnews-0.25-285.fc16.i686
libmyth-0.25_0-0.25-285.fc16.i686
libmythpostproc51-0.25-285.fc16.i686
mythplugins-0.25-285.fc16.i686
libmythfreemheg-0.25_0-0.25-285.fc16.i686
mythtv-common-0.25-285.fc16.i686
libmythupnp-0.25_0-0.25-285.fc16.i686
mythzoneminder-0.25-285.fc16.i686
libmythavfilter1-0.25-285.fc16.i686
libmythlivemedia-0.25_0-0.25-285.fc16.i686
mythweather-0.25-285.fc16.i686
libmythavdevice52-0.25-285.fc16.i686
mythbrowser-0.25-285.fc16.i686
mythes-en-3.0-8.fc15.noarch

many thanks

Jerome

Re: mythtv 0.25 segmentation faults with mythpreviewgen and mythmetadatalookup [ In reply to ]

jerome at hettich

Apr 16, 2012, 1:18 PM

Post #2 of 4 (1892 views)

Permalink

Update - some progress made -

following a reboot it actually appears that neither mythbackend and
mythfrontend would run either (immediate seg fault for these too)

however removing and reinstalling 0.25-285 rpms seems to have
(temporarily?) resolved this. ie:

yum remove mythtv*
yum remove libmythtv*
yum install mythtv

and everything now seems to be working...

no idea why this would be - so any suggestions as to what was going on
would be very helpful so I can prevent this happening again. Why would
removing an reinstalling the same rpm cure the seg faults - this isn't
windows!?!

On 15 April 2012 22:51, Jerome Hettich <jerome@hettich.org.uk> wrote:

> Hi all,
>
> have just upgraded a F16 mythtv 0.24 system (combined backend/frontend) to
> 0.24 via installing the 25-284 and then 0.25-285 rpms - thanks for
> providing these Axel!
>
> most things (recording and frontend) seem to be working fine but the
> backend log contains a number of:
> 2012-04-15 22:22:19.546395 E [1764/27581] HttpServer200
> previewgenerator.cpp:254 (Run) - Preview: Encountered problems running
> '/usr/bin/mythpreviewgen --size 0x0 --chanid 2007 --starttime
> 20120415214700 --outfile "/media/recordings/2007_20120415214700.mpg.png"
> --verbose general --logpath /var/log/mythtv --loglevel info --quiet' (140)
>
> and running mythpreviewgen (and mythmetadatalookup) with any paramaters
> just seems to result in seg fault:
> [mythtv@Beaker ~]$ mythpreviewgen
> Segmentation fault
> [mythtv@Beaker ~]$ mythmetadatalookup
> Segmentation fault
>
> Can anyone suggest any steps to help diagnose this issue (or is this a
> question for the mythtv users list)?
>
> Additional info:
> a few days prior to upgrading to 0.25 I fully working 0.24 (0.24-280) to
> 0.24.2-281 and after this update all mythprograms just seg faulted
> (mythbackend, mythfrontend and mythtv-setup). It is very possible yum would
> have updated other things at the same time but yum.log does not stretch
> back this far - so I have not been able to establish what this would have
> been.
>
> any help greatly appreciated!
>
> [mythtv@Beaker ~]$ rpm -qa|grep myth
> libmythprotoserver-0.25_0-0.25-285.fc16.i686
> libmythswscale0-0.25-285.fc16.i686
> mythtv-0.25-285.fc16.i686
> ,,,
>

Re: mythtv 0.25 segmentation faults with mythpreviewgen and mythmetadatalookup [ In reply to ]

neil at fnxweb

Apr 17, 2012, 12:43 AM

Post #3 of 4 (1879 views)

Permalink

Around about 16/04/12 21:18, Jerome Hettich typed ...
> and everything now seems to be working...
> no idea why this would be - so any suggestions as to what was going on
> would be very helpful so I can prevent this happening again.

If there was a small hole in the PRM deps., you may have been missing a
0.25 lib. that was falling back to an old 0.24 one you still had installed
(although .so numbering should account for that).

Often some old lib detritus is left behind by myth upgrades due to RPM
library name changes (e.g., not libmythx but libmythx_0.24 abd
libmythx_0.25â€). Since by what you typed you blew away *all* myth RPMs, and
pulled the *lot* in afresh, that would have cleared it all up.

The sort of things I do in this sort of situation usually start with
'strace problemprogram' to see what happens just before the crash, and in
this case probably 'ldd /path/to/problemprogram' to see what libs it thinks
it wants (watching for rogue versions) and 'strace -eopen problemprogram' to
see what lib files it's actually opening.

In this case I'd probably have removed *[Mm]yth*0.24* [is yum case
dependant?] as well, as if it was a rogue library you'd have then got a
run-time error reporting a missing library.

--
[neil@fnx ~]# rm -f .signature
[neil@fnx ~]# ls -l .signature
ls: .signature: No such file or directory
[neil@fnx ~]# exit

_______________________________________________
atrpms-users mailing list
atrpms-users@atrpms.net
http://lists.atrpms.net/mailman/listinfo/atrpms-users

Re: mythtv 0.25 segmentation faults with mythpreviewgen and mythmetadatalookup [ In reply to ]

jerome at hettich

Apr 17, 2012, 1:45 PM

Post #4 of 4 (1874 views)

Permalink

thanks Neil - for this very useful and informative reply.

Jerome

On 17 April 2012 08:43, Neil Bird <neil@fnxweb.com> wrote:

> Around about 16/04/12 21:18, Jerome Hettich typed ...
>
> and everything now seems to be working...
>> no idea why this would be - so any suggestions as to what was going on
>> would be very helpful so I can prevent this happening again.
>>
>
> If there was a small hole in the PRM deps., you may have been missing a
> 0.25 lib. that was falling back to an old 0.24 one you still had installed
> (although .so numbering should account for that).
>
> Often some old lib detritus is left behind by myth upgrades due to RPM
> library name changes (e.g., not libmythx but libmythx_0.24 abd
> libmythx_0.25”). Since by what you typed you blew away *all* myth RPMs,
> and pulled the *lot* in afresh, that would have cleared it all up.
>
>
> The sort of things I do in this sort of situation usually start with
> 'strace problemprogram' to see what happens just before the crash, and in
> this case probably 'ldd /path/to/problemprogram' to see what libs it thinks
> it wants (watching for rogue versions) and 'strace -eopen problemprogram'
> to see what lib files it's actually opening.
>
> In this case I'd probably have removed *[Mm]yth*0.24* [is yum case
> dependant?] as well, as if it was a rogue library you'd have then got a
> run-time error reporting a missing library.
>
> --
> [neil@fnx ~]# rm -f .signature
> [neil@fnx ~]# ls -l .signature
> ls: .signature: No such file or directory
> [neil@fnx ~]# exit
>
>
> ______________________________**_________________
> atrpms-users mailing list
> atrpms-users@atrpms.net
> http://lists.atrpms.net/**mailman/listinfo/atrpms-users<http://lists.atrpms.net/mailman/listinfo/atrpms-users>