Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 747337 - media-video/ffmpeg-4.3.1: Unbreak av_malloc_max(0) API/ABI
Summary: media-video/ffmpeg-4.3.1: Unbreak av_malloc_max(0) API/ABI
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: media-video herd
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-08 15:09 UTC by Joakim Tjernlund
Modified: 2020-11-25 09:03 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Unbreak av_malloc_max(0) API/ABI (0001-Unbreak-av_malloc_max-0-API-ABI.patch,1.55 KB, patch)
2020-10-08 15:09 UTC, Joakim Tjernlund
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joakim Tjernlund 2020-10-08 15:09:06 UTC
Created attachment 664390 [details, diff]
Unbreak av_malloc_max(0) API/ABI

From https://bugs.chromium.org/p/chromium/issues/detail?id=1095962
----------------------------
This seems to be caused by the custom handling of "av_max_alloc(0)" in
Chromium's ffmpeg fork to mean unlimited (added in [1]).

Upstream ffmpeg doesn't treat 0 as a special value; versions before 4.3 seemingly worked
because 32 was subtracted from max_alloc_size (set to 0 by Chromium) resulting in an
integer underflow, making the effective limit be SIZE_MAX - 31.

Now that the above underflow doesn't happen, the tab just crashes. The upstream change
for no longer subtracting 32 from max_alloc_size was included in ffmpeg 4.3. [2]

[1] https://chromium-review.googlesource.com/c/chromium/third_party/ffmpeg/+/73563
[2] https://github.com/FFmpeg/FFmpeg/commit/731c77589841
---------------------------

Restore av_malloc_max(0) to MAX_INT fixing MS Teams, Discord older chromium etc.
Comment 1 Alexis Ballier gentoo-dev 2020-10-09 16:45:49 UTC
I'm not fond of that hack and I'd rather see the consumers use INT_MAX instead of 0...

However, if this patch gets accepted upstream, then I'm fine with having it backported.
Comment 2 Joakim Tjernlund 2020-10-10 09:15:25 UTC
(In reply to Alexis Ballier from comment #1)
> I'm not fond of that hack and I'd rather see the consumers use INT_MAX
> instead of 0...

Sure, but that will take time and we need to still be able to use these apps
which are binary only so we cannot fix then ourself.

> 
> However, if this patch gets accepted upstream, then I'm fine with having it
> backported.

If upstream does not take it I think Gentoo should until apps has been fixed
Comment 3 Alexis Ballier gentoo-dev 2020-10-10 13:23:20 UTC
(In reply to Joakim Tjernlund from comment #2)

> > 
> > However, if this patch gets accepted upstream, then I'm fine with having it
> > backported.
> 
> If upstream does not take it I think Gentoo should until apps has been fixed

It is not really our role to define the ABI & API of upstream libraries :/
Plus, if they do not take it, they would have good reasons that I would like to hear.
Comment 4 Joakim Tjernlund 2020-10-11 09:34:03 UTC
Speaking of upstream, I posted the patch to their dev mail list but it it
seems stuck.
Anyone here close to upstream that can bring this patch to their attention?
Comment 5 Alexis Ballier gentoo-dev 2020-10-11 12:36:18 UTC
(In reply to Joakim Tjernlund from comment #4)
> Speaking of upstream, I posted the patch to their dev mail list but it it
> seems stuck.
> Anyone here close to upstream that can bring this patch to their attention?

Do you have a link ?
I can't seem to find it.

Usually it's ok to send a friendly ping if no answer for >1 week.
Comment 6 Joakim Tjernlund 2020-10-11 14:42:13 UTC
(In reply to Alexis Ballier from comment #5)
> (In reply to Joakim Tjernlund from comment #4)
> > Speaking of upstream, I posted the patch to their dev mail list but it it
> > seems stuck.
> > Anyone here close to upstream that can bring this patch to their attention?
> 
> Do you have a link ?
> I can't seem to find it.

No I do not. Seems like it never got though the mail list. I guess
they don't let non subscribers into the list but I did not get any rejection reply  either.
Comment 7 Sam James archtester gentoo-dev Security 2020-10-11 15:06:45 UTC
(In reply to Joakim Tjernlund from comment #6)
> (In reply to Alexis Ballier from comment #5)
> > (In reply to Joakim Tjernlund from comment #4)
> > > Speaking of upstream, I posted the patch to their dev mail list but it it
> > > seems stuck.
> > > Anyone here close to upstream that can bring this patch to their attention?
> > 
> > Do you have a link ?
> > I can't seem to find it.
> 
> No I do not. Seems like it never got though the mail list. I guess
> they don't let non subscribers into the list but I did not get any rejection
> reply  either.

Subscribe and try again?
Comment 8 Joakim Tjernlund 2020-10-11 15:22:33 UTC
(In reply to Sam James from comment #7)
> (In reply to Joakim Tjernlund from comment #6)
> > (In reply to Alexis Ballier from comment #5)
> > > (In reply to Joakim Tjernlund from comment #4)
> > > > Speaking of upstream, I posted the patch to their dev mail list but it it
> > > > seems stuck.
> > > > Anyone here close to upstream that can bring this patch to their attention?
> > > 
> > > Do you have a link ?
> > > I can't seem to find it.
> > 
> > No I do not. Seems like it never got though the mail list. I guess
> > they don't let non subscribers into the list but I did not get any rejection
> > reply  either.
> 
> Subscribe and try again?

I am afraid I have reached my limit here, so no.
Got my users covered, if Gentoo won't for policy reasons only there is
not much I can do.
Comment 9 Joakim Tjernlund 2020-10-13 10:33:30 UTC
(In reply to Sam James from comment #7)
> (In reply to Joakim Tjernlund from comment #6)
> > (In reply to Alexis Ballier from comment #5)
> > > (In reply to Joakim Tjernlund from comment #4)
> > > > Speaking of upstream, I posted the patch to their dev mail list but it it
> > > > seems stuck.
> > > > Anyone here close to upstream that can bring this patch to their attention?
> > > 
> > > Do you have a link ?
> > > I can't seem to find it.
> > 
> > No I do not. Seems like it never got though the mail list. I guess
> > they don't let non subscribers into the list but I did not get any rejection
> > reply  either.
> 
> Subscribe and try again?

OK, so I caved and subscribed just to post a simple patch:
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-October/270977.html
Comment 10 Martin Cihlář 2020-10-14 06:51:00 UTC
(In reply to Joakim Tjernlund from comment #9)
> OK, so I caved and subscribed just to post a simple patch:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-October/270977.html

Oh, fun thread. On one hand, I understand the ffmpeg devs hesitant to restore undocumented behaviour, but on the other, breaking applications (wrongly) using this behaviour is not a commendable decision.

This unfortunately seems to be common behaviour in the FOSS camp and the exact opposite of the proprietary, enterprise software camp - take MS, they will carry all the legacy hacks and cruft just to make sure that all the customers' applications still work.

Either way, thank you Joakim for doing the legwork on this one.
Comment 11 Joakim Tjernlund 2020-10-14 16:03:01 UTC
(In reply to Martin Cihlář from comment #10)
> (In reply to Joakim Tjernlund from comment #9)
> > OK, so I caved and subscribed just to post a simple patch:
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-October/270977.html
> 
> Oh, fun thread. On one hand, I understand the ffmpeg devs hesitant to
> restore undocumented behaviour, but on the other, breaking applications
> (wrongly) using this behaviour is not a commendable decision.
> 
> This unfortunately seems to be common behaviour in the FOSS camp and the
> exact opposite of the proprietary, enterprise software camp - take MS, they
> will carry all the legacy hacks and cruft just to make sure that all the
> customers' applications still work.
> 
> Either way, thank you Joakim for doing the legwork on this one.

Thanks, not sure they are that much opposed, more that then want a more complete
patch. We will see ...
Comment 12 Sam James archtester gentoo-dev Security 2020-10-14 16:09:52 UTC
(In reply to Joakim Tjernlund from comment #11)
> (In reply to Martin Cihlář from comment #10)
> > (In reply to Joakim Tjernlund from comment #9)
> > > OK, so I caved and subscribed just to post a simple patch:
> > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-October/270977.html
> > 
> > Oh, fun thread. On one hand, I understand the ffmpeg devs hesitant to
> > restore undocumented behaviour, but on the other, breaking applications
> > (wrongly) using this behaviour is not a commendable decision.
> > 
> > This unfortunately seems to be common behaviour in the FOSS camp and the
> > exact opposite of the proprietary, enterprise software camp - take MS, they
> > will carry all the legacy hacks and cruft just to make sure that all the
> > customers' applications still work.
> > 
> > Either way, thank you Joakim for doing the legwork on this one.
> 
> Thanks, not sure they are that much opposed, more that then want a more
> complete
> patch. We will see ...

I do genuinely appreciate the effort here, by the way. I'm just wary about modifying a core application without upstream consent. Thank you.
Comment 13 Joakim Tjernlund 2020-10-18 18:25:45 UTC
James, since you now work for MS I figure you might be interested in this bug
Comment 14 Joakim Tjernlund 2020-11-25 09:03:11 UTC
1.3.00.30857 came a few days ago but the problem persists.

I have given up on upstream ffmpeg too as then cannot make a decision.