Backend segfault in preview generation

[justifiably@…]

Sometimes there seem to be problems generating previews on the watch recording screen for me, which have recently caused the backend to segfault (and also the frontend). I'm not sure why: at first I thought they were buggy files (e.g. with empty previews). Nonetheless the front or backends shouldn't segfault! I've done some more testing and now see the issue for transcoded files which can be successfully played back otherwise (e.g. in mplayer).

This is on svn 8631 but I've seen the issue over the past few releases.

I'll followup with a backtrace for the backend which reports glibc catching an invalid free call.

[justifiably@…]

log fragment from backend, inc glibc error (gdb terminal output)

[danielk]

patch that increases verbosity in possible problem areas

[danielk]

Please reproduce the problem with the attached patch applied using '-v playback,record'

This may be a duplicate of #929, but I don't have enough information yet.

BTW As far as you know was this file being autoexpired as the preview was being generated?

[danielk]

(In [8635]) References #1052.

Marks the PreviewGenerator?'s ProgramInfo? as in use while generating the preview. This should prevent it from being AutoExpired? while the preview is being generated. It looks like AutoExpire? had just run when justifiably AT cwazy dot co.uk's crash happened.

[justifiably@…]

Thanks for swift response Daniel.

I don't think this was because of auto expire running, I still have the shows with the problematic preview generation and I can repeat the crash at will. There's a possibility they are recordings that had been interrupted by backend restarts/crashes, I'm not sure yet --- but they have survived transcoding. I can crash the backend by trying to view the previews in mythweb or by the watch recordings screen.

I'm attaching a new log against rev 8640, with your patch for debugging and -v playback,record. Hope this helps.

[justifiably@…]

gdb session log

[justifiably@…]

Further note: a crash on preview viewing is also occuring on the frontend which before dying reports:

2006-01-18 15:15:14.008 Unable to find image file: /myth/recordings/ER - 2006-01-18, 12-28 AM - Dead Again.nuv.png

or (if I touch the image file to make it exist but empty)

2006-01-18 15:16:48.760 Error loading image file: /myth/recordings/ER - 2006-01-18, 12-28 AM - Dead Again.nuv.png

Is it expected that the frontend should crash in these cases? (Obviously it's not ideal --- but I wondered if I should suspect some library somewhere rather than myth). I hope it won't be needed but let me know if I should open a separate ticket/append logs for this crash.

[anonymous]

I have (almost) the same behavior on my system. When viewing certain previews for certain recordings, the frontend hangs indefinitly and the backend segfaults. The same preview, when accessed thru mythweb will also crash the backend.

I can also reproduce this problem at will... if you need anything from another source, just ask.

[justifiably@…]

Glad to know it wasn't just me!

I had just tried a completely fresh checkout/rebuild for sanity's sake, but the problem didn't magically vanish 8-(.

[danielk]

Can you try [8624], the last revision before the last ffmpeg resync. It looks like memory is being corrupted by ffmpeg when it is playing corrupted NUV files.

BTW What is the codec? NuppelVideo?/MPEG4 ?

The other thing to do is run the preview generation through valgrind. The easiest wat to do this is to delete all the png's in your recording directory and run valgrind on mythfrontend, then arrow through the recordings slowly (generating previews). If anything overwrites memory valgrind should find it.

As for the zero byte recordings causing problems, I'll fix that today.

I'm lowering the priority to 'major' and moving this to 0.20 because it appears to be an ffmpeg problem and only occur with broken files. I'll still try to fix this for 0.19.

[danielk]

Forget what I said about fixing zero length recordings, I realized you meant zero length png's when I started looking at the problem. MythTV won't generate these, and this doesn't crash on my system anyway (libpng 1.2.8).

When MythTV sees that the preview is missing when it needs one in the frontend it generates one, and I presume it is crashing for the same reason as the backend crashes on generating the same preview.

[justifiably@…]

The files are ones that have been transcoded into MPEG4 yes. I suspect you're right about this problem appearing with the ffmpeg resync: I'm rebuilding 8624 to check. Have you any idea how the files might be broken (or repaired in case so)? I tried rebuilding seektable with mythcommflag but that didn't help. I'm not certain that all of these files correspond to interrupted recordings, btw.

[justifiably@…]

Unfortunately 8624 still segfaults on the bad recordings, although it might be in a different place. Message from frontend log file:

** glibc detected *** /usr/local/bin/mythfrontend: free(): invalid next size (normal): 0x0a00ecc0 ***
======= Backtrace: =========
/lib/libc.so.6[0x1db5124]
/lib/libc.so.6(__libc_free+0x77)[0x1db565f]
/usr/local/lib/libmythavcodec-0.19.so.0(av_free+0x1f)[0xfe99df] 
======= Memory map: ========
00111000-00176000 r-xp 00000000 fd:00 364618     /usr/local/lib/libmythavformat-0.19.so.0.19.0
00176000-0017c000 rwxp 00065000 fd:00 364618     /usr/local/lib/libmythavformat-0.19.so.0.19.0
0017c000-00441000 r-xp 00000000 fd:00 364625     /usr/local/lib/libmyth-0.19.so.0.19.0
00441000-00466000 rwxp 002c5000 fd:00 364625     /usr/local/lib/libmyth-0.19.so.0.19.0
00466000-00467000 rwxp 00466000 00:00 0
... <etc> ...

[danielk]

(In [8651]) Fixes #1052.

In this case an MPEG-4 recording is using a frame height which is not a multiple of 16. ffmpeg isn't doing any validation on the dimensions so it ends up writing outside the buffer. This just pads allocated buffers up to multiples of 16, so that this type of error doesn't cause a segfault with any of the codecs we support. MythTV does prevent you from setting an invalid dimension when you record to a MPEG-4 NUV, so AFAIK this is more of a legacy issue.

[danielk]

(In [8655]) References #1052.

The new transcodepreserveaspect setting was causing the invalid framesizes. This fixes this for MPEG streams.

If there are any resolution restrictions for RTjpeg frames these should be fixed as well.