Opened 10 years ago

Closed 10 years ago

#7951 closed defect (fixed)

multiple components segfaulting in av_close_input_stream

Reported by: Andrew Dranse <ajdranse@…> Owned by: Isaac Richards
Priority: major Milestone: 0.23
Component: MythTV - General Version: 0.22-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description (last modified by paulh)

After upgrading from debian etch to lenny, and correspondingly upgrading to mythtv 0.22, it seems that every time something closes any file which was recorded by my backend (mythcommflag, mythfrontend, etc), there is a segfault in av_close_input_stream, seemingly related to freeing a pointer twice. i did some digging, and it appears that there is some sort of bad audio stream in the recorded files (below from a -v all run of mythcommflag):

2010-01-24 01:34:11.250 AFD: Using ffmpeg for video decoding
2010-01-24 01:34:11.250 AFD: Looking for decoder for MPEG2VIDEO
2010-01-24 01:34:11.250 AFD: Opened codec 0x1122180, id(MPEG2VIDEO) type(Video)
2010-01-24 01:34:11.250 AFD: Stream #1, has id 0x80 codec id AC3, type Audio, bitrate 0 at 0x1122760
2010-01-24 01:34:11.250 AFD: codec AC3 has 0 channels
2010-01-24 01:34:11.250 AFD: Looking for decoder for AC3
2010-01-24 01:34:11.251 AFD: Opened codec 0x1130560, id(AC3) type(Audio)
2010-01-24 01:34:11.251 AFD: Audio Track #1 is A/V stream #1 and has 0 channels in the German language(6776178).
2010-01-24 01:34:11.251 AFD: Stream #2, has id 0x80 codec id AC3, type Audio, bitrate 448000 at 0x1130990
2010-01-24 01:34:11.251 AFD: codec AC3 has 6 channels
2010-01-24 01:34:11.251 AFD: Looking for decoder for AC3
2010-01-24 01:34:11.252 AFD: Opened codec 0x1130ba0, id(AC3) type(Audio)
2010-01-24 01:34:11.252 AFD: Audio Track #2 is A/V stream #2 and has 6 channels in the English language(6647399).

...

2010-01-24 01:34:11.260 Input #0, mpegts, from '/mythtv/1605_20100123203800.mpg':
2010-01-24 01:34:11.260   Duration: 00:22:24.60, start: 42095.415356, bitrate: 13963 kb/s
2010-01-24 01:34:11.260     Stream #0.0[0xe0]: Video: mpeg2video, yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 1001/60000, 65000 kb/s, 29.97 tbr, 90k tbn, 59.94 tbc
2010-01-24 01:34:11.260     Stream #0.1[0x80]: Audio: ac3, 0 channels, s16
2010-01-24 01:34:11.260     Stream #0.2[0x80]: Audio: ac3, 48000 Hz, 2 channels (FL|FR|FC|LFE|SL|SR), s16, 448 kb/s

Stream #0.1 is a german language, 0 channel stream, which seems odd.

I built the tip (r23254) of the 0.22-fixes branch and replicated the problem.

I will attach the output from running a debug build "mythcommflag --video bad_file.mpg" which results in the segfault. I can provide the video file as well if required (it is 5MB).

Attachments (1)

gdb_out.txt (12.3 KB) - added by Andrew Dranse <ajdranse@…> 10 years ago.

Download all attachments as: .zip

Change History (8)

Changed 10 years ago by Andrew Dranse <ajdranse@…>

Attachment: gdb_out.txt added

comment:1 Changed 10 years ago by stuartm

Milestone: unknown0.23
Priority: minorcritical
Status: newinfoneeded_new

Andrew can you make available the clip which triggers the segfault? Since Trac is limited to 512Kb attachments, I suggest http://filebin.ca/

comment:2 Changed 10 years ago by danielk

There is an insufficiently documented ugly hack on line 2037 of avformatdecoder.cpp

//av_close_input_file(ic); // causes segfault

which may be related. As a general rule all ffmpeg file, stream & codec object creation and teardown routines need to be protected by a global lock as they are neither thread-safe nor re-entrant code. The lack of avcodeclock locking in some such locations is probably the cause of the instability.

comment:3 Changed 10 years ago by Andrew Dranse <ajdranse@…>

Uploaded to http://filebin.ca/ngvsb/bad_file.mpg as requested.

comment:4 Changed 10 years ago by paulh

Description: modified (diff)
Status: infoneeded_newnew

comment:5 Changed 10 years ago by sphery

I'm unable to reproduce a segfault using mythfrontend or mythcommflag with the supplied file. I got a lot of libav* errors in the logs, and I didn't get a picture during playback, but I don't know if that's because of playback issues or because the clip is so short.

comment:6 Changed 10 years ago by Janne Grunau

Priority: criticalmajor

yes, it seems that the buggy metadata in the PMT are causing the double free. The PMT reports two AC3 streams on the same PID. This seems to be fixed by the ffmpeg sync sinc 0.23-fixes report only one audio stream.

comment:7 Changed 10 years ago by Janne Grunau

Resolution: fixed
Status: newclosed

closing as fixed, please reopen if it's still reproduceable with other samples and upload a new sample.

Note: See TracTickets for help on using tickets.