Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#831591: ffmpeg: kodi crash
41 views
Skip to first unread message
Balint Reczey
Nov 3, 2016, 8:00:02 AM11/3/16
to
Control: forwarded -1 https://github.com/xbmc/xbmc/pull/10846
Control: tags -1 upstream
Hi Andreas,
On Fri, 14 Oct 2016 01:27:47 +0200 Andreas Cadhalpun
<andreas....@googlemail.com> wrote:
...
>
> Hi,
>
> The relevant backtrace from the kodi_crashlog is:
>
> Thread 1 (Thread 0x7f1b6bffe700 (LWP 16893)):
> #0 0x00007f1ba92991c8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
> #1 0x00007f1ba929a64a in __GI_abort () at abort.c:89
> #2 0x00007f1ba92d4f4a in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f1ba93cdb30 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
> #3 0x00007f1ba92da6b6 in malloc_printerr (action=3, str=0x7f1ba93ca909 "free(): invalid pointer", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5004
> #4 0x00007f1ba92dae9e in _int_free (av=0x7f1ba9601b20 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3865
> #5 0x00007f1baa6d4a9d in av_buffer_unref () from /usr/lib/x86_64-linux-gnu/libavutil.so.55
> #6 0x00007f1baa6e15d2 in av_frame_unref () from /usr/lib/x86_64-linux-gnu/libavutil.so.55
> #7 0x00007f1bab93cf10 in avcodec_decode_video2 () from /usr/lib/x86_64-linux-gnu/libavcodec.so.57
> #8 0x000000000090b26c in CDVDDemuxFFmpeg::ParsePacket(AVPacket*) ()
> #9 0x000000000090d0c2 in CDVDDemuxFFmpeg::Read() ()
> #10 0x0000000001079b53 in CDVDPlayer::ReadPacket(DemuxPacket*&, CDemuxStream*&) ()
> #11 0x000000000107ecd7 in CDVDPlayer::Process() ()
> #12 0x00000000012103ff in CThread::Action() ()
> #13 0x00000000012106bf in CThread::staticThread(void*) ()
> #14 0x00007f1bb23e5464 in start_thread (arg=0x7f1b6bffe700) at pthread_create.c:333
> #15 0x00007f1ba934d30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>
> Looking at the ParsePacket function reveals [1]:
> AVFrame picture;
> memset(&picture, 0, sizeof(AVFrame));
> picture.pts = picture.pkt_dts = picture.pkt_pts = picture.best_effort_timestamp = AV_NOPTS_VALUE;
> picture.pkt_pos = -1;
> picture.key_frame = 1;
> picture.format = -1;
>
> This is using non-public ABI, e.g. the size of AVFrame, while the documentation
> explicitly says "sizeof(AVFrame) is not a part of the public ABI" [2].
> What's worse is that it doesn't use av_frame_alloc as required [3]:
> "AVFrame must be allocated using av_frame_alloc()."
>
> The whole block quoted above should be replaced with:
> AVFrame *picture = av_frame_alloc().
>
> Then the following code should use picture instead of &picture:
> avcodec_decode_video2(st->codec, picture, &got_picture, pkt);
>
> And at the end it can be freed (instead of using av_frame_unref) with:
> av_frame_free(&picture);
>
> In the experimental kodi branch there is another occurrence of this bug
> in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.
Thank you for the triaging and extensive description of the problem.
I have now forwarded the patch to upstream under your name since I did
not really add anything to the patch.
>
> Best regards,
> Andreas
>
>
> 1: https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git/tree/xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.cpp?id=8d5cf423001aa4e7f850c20b158b2811e637e607#n1665
> 2: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n174
> 3: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n154
>
>
Control: tags -1 upstream
Hi Andreas,
On Fri, 14 Oct 2016 01:27:47 +0200 Andreas Cadhalpun
<andreas....@googlemail.com> wrote:
...
>
> Hi,
>
> The relevant backtrace from the kodi_crashlog is:
>
> Thread 1 (Thread 0x7f1b6bffe700 (LWP 16893)):
> #0 0x00007f1ba92991c8 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
> #1 0x00007f1ba929a64a in __GI_abort () at abort.c:89
> #2 0x00007f1ba92d4f4a in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f1ba93cdb30 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
> #3 0x00007f1ba92da6b6 in malloc_printerr (action=3, str=0x7f1ba93ca909 "free(): invalid pointer", ptr=<optimized out>, ar_ptr=<optimized out>) at malloc.c:5004
> #4 0x00007f1ba92dae9e in _int_free (av=0x7f1ba9601b20 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3865
> #5 0x00007f1baa6d4a9d in av_buffer_unref () from /usr/lib/x86_64-linux-gnu/libavutil.so.55
> #6 0x00007f1baa6e15d2 in av_frame_unref () from /usr/lib/x86_64-linux-gnu/libavutil.so.55
> #7 0x00007f1bab93cf10 in avcodec_decode_video2 () from /usr/lib/x86_64-linux-gnu/libavcodec.so.57
> #8 0x000000000090b26c in CDVDDemuxFFmpeg::ParsePacket(AVPacket*) ()
> #9 0x000000000090d0c2 in CDVDDemuxFFmpeg::Read() ()
> #10 0x0000000001079b53 in CDVDPlayer::ReadPacket(DemuxPacket*&, CDemuxStream*&) ()
> #11 0x000000000107ecd7 in CDVDPlayer::Process() ()
> #12 0x00000000012103ff in CThread::Action() ()
> #13 0x00000000012106bf in CThread::staticThread(void*) ()
> #14 0x00007f1bb23e5464 in start_thread (arg=0x7f1b6bffe700) at pthread_create.c:333
> #15 0x00007f1ba934d30d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
>
> Looking at the ParsePacket function reveals [1]:
> AVFrame picture;
> memset(&picture, 0, sizeof(AVFrame));
> picture.pts = picture.pkt_dts = picture.pkt_pts = picture.best_effort_timestamp = AV_NOPTS_VALUE;
> picture.pkt_pos = -1;
> picture.key_frame = 1;
> picture.format = -1;
>
> This is using non-public ABI, e.g. the size of AVFrame, while the documentation
> explicitly says "sizeof(AVFrame) is not a part of the public ABI" [2].
> What's worse is that it doesn't use av_frame_alloc as required [3]:
> "AVFrame must be allocated using av_frame_alloc()."
>
> The whole block quoted above should be replaced with:
> AVFrame *picture = av_frame_alloc().
>
> Then the following code should use picture instead of &picture:
> avcodec_decode_video2(st->codec, picture, &got_picture, pkt);
>
> And at the end it can be freed (instead of using av_frame_unref) with:
> av_frame_free(&picture);
>
> In the experimental kodi branch there is another occurrence of this bug
> in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.
Thank you for the triaging and extensive description of the problem.
I have now forwarded the patch to upstream under your name since I did
not really add anything to the patch.
>
> Best regards,
> Andreas
>
>
> 1: https://anonscm.debian.org/cgit/pkg-multimedia/kodi.git/tree/xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.cpp?id=8d5cf423001aa4e7f850c20b158b2811e637e607#n1665
> 2: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n174
> 3: https://anonscm.debian.org/cgit/pkg-multimedia/ffmpeg.git/tree/libavutil/frame.h?id=87b93f4e3ee2b6253ab9f5a166860a1ff18877d5#n154
>
>
Bálint Réczey
Nov 3, 2016, 8:10:03 AM11/3/16
to
2016-11-03 12:54 GMT+01:00 Balint Reczey <bal...@balintreczey.hu>:
...
that would be geat.
Cheers,
Balint
...
> On Fri, 14 Oct 2016 01:27:47 +0200 Andreas Cadhalpun
> <andreas....@googlemail.com> wrote:
> ...
>
>>
>> Hi,
>>
>> The relevant backtrace from the kodi_crashlog is:
...
> <andreas....@googlemail.com> wrote:
> ...
>
>>
>> Hi,
>>
>> The relevant backtrace from the kodi_crashlog is:
>> In the experimental kodi branch there is another occurrence of this bug
>> in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.
>
> Thank you for the triaging and extensive description of the problem.
> I have now forwarded the patch to upstream under your name since I did
> not really add anything to the patch.
If someone having the test file could test latest kodi in unstable
>> in xbmc/cores/VideoPlayer/VideoRenderers/HwDecRender/MMALRenderer.cpp.
>
> Thank you for the triaging and extensive description of the problem.
> I have now forwarded the patch to upstream under your name since I did
> not really add anything to the patch.
that would be geat.
Cheers,
Balint
Andreas Cadhalpun
Nov 3, 2016, 6:10:02 PM11/3/16
to
Hi Bálint,
On 03.11.2016 13:00, Bálint Réczey wrote:
> 2016-11-03 12:54 GMT+01:00 Balint Reczey <bal...@balintreczey.hu>:
>> Thank you for the triaging and extensive description of the problem.
>> I have now forwarded the patch to upstream under your name since I did
>> not really add anything to the patch.
The patch looks good, thanks for forwarding it upstream. (Even though
one of the upstream developers has some peculiar ideas about correct
code.)
> If someone having the test file could test latest kodi in unstable
> that would be geat.
There is a test file[1] in one of the merged bugs.
However, testing the latest kodi in unstable is of limited use, since
it was built against the same ffmpeg version currently in unstable.
If you want to verify that the problem is fixed, you'd have to recompile
kodi against 3.0.1 and test it with the current ffmpeg libraries (or
the ones from 3.1.1).
Best regards,
Andreas
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=832364;filename=test2.ts.gz;msg=67
On 03.11.2016 13:00, Bálint Réczey wrote:
> 2016-11-03 12:54 GMT+01:00 Balint Reczey <bal...@balintreczey.hu>:
>> Thank you for the triaging and extensive description of the problem.
>> I have now forwarded the patch to upstream under your name since I did
>> not really add anything to the patch.
one of the upstream developers has some peculiar ideas about correct
code.)
> If someone having the test file could test latest kodi in unstable
> that would be geat.
However, testing the latest kodi in unstable is of limited use, since
it was built against the same ffmpeg version currently in unstable.
If you want to verify that the problem is fixed, you'd have to recompile
kodi against 3.0.1 and test it with the current ffmpeg libraries (or
the ones from 3.1.1).
Best regards,
Andreas
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=832364;filename=test2.ts.gz;msg=67
Bálint Réczey
Nov 6, 2016, 9:20:03 AM11/6/16
to
Hi Andreas,
2016-11-03 23:06 GMT+01:00 Andreas Cadhalpun <andreas....@googlemail.com>:
> Hi Bálint,
>
> On 03.11.2016 13:00, Bálint Réczey wrote:
>> 2016-11-03 12:54 GMT+01:00 Balint Reczey <bal...@balintreczey.hu>:
>>> Thank you for the triaging and extensive description of the problem.
>>> I have now forwarded the patch to upstream under your name since I did
>>> not really add anything to the patch.
>
> The patch looks good, thanks for forwarding it upstream. (Even though
> one of the upstream developers has some peculiar ideas about correct
> code.)
>
>> If someone having the test file could test latest kodi in unstable
>> that would be geat.
>
> There is a test file[1] in one of the merged bugs.
> However, testing the latest kodi in unstable is of limited use, since
> it was built against the same ffmpeg version currently in unstable.
>
> If you want to verify that the problem is fixed, you'd have to recompile
> kodi against 3.0.1 and test it with the current ffmpeg libraries (or
> the ones from 3.1.1).
Thank you for pointing to the test file. Proper testing would involve
a recompilation indeed, but since upstream does not want to
merge the patch anyway I don't feel this kind of testing necessary.
Cheers,
Balint
2016-11-03 23:06 GMT+01:00 Andreas Cadhalpun <andreas....@googlemail.com>:
> Hi Bálint,
>
> On 03.11.2016 13:00, Bálint Réczey wrote:
>> 2016-11-03 12:54 GMT+01:00 Balint Reczey <bal...@balintreczey.hu>:
>>> Thank you for the triaging and extensive description of the problem.
>>> I have now forwarded the patch to upstream under your name since I did
>>> not really add anything to the patch.
>
> The patch looks good, thanks for forwarding it upstream. (Even though
> one of the upstream developers has some peculiar ideas about correct
> code.)
>
>> If someone having the test file could test latest kodi in unstable
>> that would be geat.
>
> There is a test file[1] in one of the merged bugs.
> However, testing the latest kodi in unstable is of limited use, since
> it was built against the same ffmpeg version currently in unstable.
>
> If you want to verify that the problem is fixed, you'd have to recompile
> kodi against 3.0.1 and test it with the current ffmpeg libraries (or
> the ones from 3.1.1).
a recompilation indeed, but since upstream does not want to
merge the patch anyway I don't feel this kind of testing necessary.
Cheers,
Balint
0 new messages