mythcommflag segfaulting

[brian@…]

I seem to have a situation here on master where mythcommflag is segfaulting somewhat frequently:

2011-12-18 20:12:57.796294 E [14020/26341] Commflag_5275 jobqueue.cpp:2334 (DoFlagCommercialsThread) - JobQueue: Commercial Detection Errored: "Survivor: South Pacific":"Loyalties Will Be Broken" re
corded from channel 2917 at 2011-12-18T20:00:00 (Failed with exit status 139)

Corroborated by the kernel:

Dec 18 20:12:57 pvr kernel: [664047.258897] mythcommflag[26417]: segfault at b3dfb000 ip 00d2252e sp b63f8a68 error 6 in libmythswscale.so.0.12.0[cec000+56000]

Unfortunately until just now (I just changed it) the corefile size ulimit of the backend process was 0. Hopefully the next time this happens, I will get a core file.

Alternatively, I still have the recording that caused the segfault. Any suggestions on command line parameters to run mythcommflag with to reproduce the segfault (i.e. what would mythbackend have called mythcommflag with)?

[robertm]

Setting as infoneeded until a backtrace is provided

[brian@…]

Here's a backtrace:

#0  mpeg2_fast_decode_block_non_intra (s1=<value optimized out>, mb_y=146783056, buf=0xb08a2c58, buf_size=554) at libavcodec/mpeg12.c:956
#1  mpeg_decode_mb (s1=<value optimized out>, mb_y=146783056, buf=0xb08a2c58, buf_size=554) at libavcodec/mpeg12.c:533
#2  mpeg_decode_slice (s1=<value optimized out>, mb_y=146783056, buf=0xb08a2c58, buf_size=554) at libavcodec/mpeg12.c:1729
#3  0x039e1217 in decode_chunks (avctx=0x8b7a050, picture=0xb08a2df0, data_size=0xb08a2de4, buf=0xb1e76cd0 "", buf_size=36403) at libavcodec/mpeg12.c:2628
#4  0x039e4a29 in mpeg_decode_frame (avctx=0x8b7a050, data=0xb08a2df0, data_size=0xb08a2de4, avpkt=0xb1e07c38) at libavcodec/mpeg12.c:2430
#5  0x03ae99a1 in avcodec_decode_video2 (avctx=0x8b7a050, picture=0xb08a2df0, got_picture_ptr=0xb08a2de4, avpkt=0xb1e07c38) at libavcodec/utils.c:667
#6  0x01207927 in AvFormatDecoder::ProcessVideoPacket (this=0x8b78610, curstream=0x8b63dc0, pkt=0xb1e07c38) at avformatdecoder.cpp:3043
#7  0x01209318 in AvFormatDecoder::GetFrame (this=0x8b78610, decodetype=kDecodeAV) at avformatdecoder.cpp:4440
#8  0x0117a16b in MythPlayer::DecoderGetFrame (this=0x8b17930, decodetype=516, unsafe=64) at mythplayer.cpp:3100
#9  0x0117a4b7 in MythPlayer::DecoderLoop (this=0x8b17930, pause=false) at mythplayer.cpp:3024
#10 0x0116a68e in DecoderThread::run (this=0x8b97758) at mythplayer.cpp:93
#11 0x00af5522 in MThreadInternal::run (this=0x8c05818) at mthread.cpp:77
#12 0x0517eda2 in ?? () from /usr/lib/libQtCore.so.4
#13 0x034dba9c in ?? ()
#14 0x00000000 in ?? ()

[brian@…]

Since I've provided the backtrace can we at least change this ticket's status from infoneeded_new so that it doesn't look like it's waiting for action from the reporter in summaries, etc.?

[robertm]

Are you using the "experimental" commflag speedups? This crash isn't in Myth code, it's in ffmpeg. Based on the method name it appears that you are using those speedups, which carry the experimental tag for precisely this reason. You may be able to work around this by using the traditional decoding/commflagging methods, but ultimately, the crash isn't in code we maintain so there is little we can probably do for this one.

[brian@…]

Ahh. I don't think I am using those experimental methods. On a given FE here, in the "General (Jobs)" (Setup->Video->General) setup screen I have:

Commercial detection method: All Available Methods [ ] Enable experimental speedup of commercial detection [ ] Strict commercial detection

(both checkboxes are unchecked)

[kenneth.emerson@…]

Rather than open a new (almost identical) ticket, I will attach a new backtrace that appears to be inside the myth code.

mythtv@mythtv:/mythtv/data$ /mythbuild/new/bin/mythcommflag --version Please attach all output as a file in bug reports. MythTV Version : v0.25pre-4101-g2897134 MythTV Branch : master Network Protocol : 71 Library API : 0.25.20120122-1 QT Version : 4.6.2 Options compiled in:

linux debug use_hidesyms using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_bindings_php using_dvb using_firewire using_frontend using_hdhomerun using_ceton using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_libxml2 using_libudf using_lirc using_mheg using_opengl_video using_qtwebkit using_qtscript using_qtdbus using_v4l2 using_v4l1 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_bindings_php using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg using_libxml2 using_libudf

[Ken Emerson <kenneth.emerson@…>]

mythcommflag segfault backtrace

[brian@…]

FWIW, this is almost assuredly being caused by a recording with corruption in it (likely due to #10414 -- but that has yet to be verified given that the fix for that is still so new).

These same recordings are however playable with mplayer and with the mythfrontend player so it seems reasonable that mythcommflag should be able to deal with them also and not segfault.

[beirdo]

We will look into the possibility of keeping corrupted files from crashing mythcommflag later on. The problem is that the offending code is potentially quite deep into ffmpeg library code (as your backtrace shows). This makes it quite time consuming to trace down, and really, in the end, it's only a minor inconvenience on files that are already questionable for playback.

If this continues with 0.25 after the release, feel free to open a new ticket and we'll take another look at it, but early after the release, I plan to do another ffmpeg sync, so please wait until after that point.

[brian@…]

Is this ffmpeg re-sync something that's going to end up in 0.25-fixes or will it be in master/0.26 only? If the former, how will I know when it has landed so that I can re-test? I.e.: is there a ticket tracking this work that I can subscribe to?

[Jim Stichnoth]

There is a possibility that mythcommflag could segfault as a result of the condition that was fixed in [dfadcda17].

[thomas-joiner <thomas.b.joiner@…>]

I have created a pull request (​https://github.com/MythTV/mythtv/pull/37) that fixes this issue. The problem was that a dangerous flag was being used (more or less) indiscriminately.

[Kenni Lund [kenni a kelu dot dk]]

thomas-joiner, please create a new ticket with your findings and your pull request, otherwise it will just get lost in here.

[Stuart Auchterlonie <stuarta@…>]

In aaa5255f5bdf90233846e4c5c17e5d61fd7d500a/mythtv:

Merge remote-tracking branch 'thomas-joiner/bug_10222'

​https://github.com/MythTV/mythtv/pull/37

Refs #10222
Closes #11411

Signed-off-by: Stuart Auchterlonie <stuarta@…>