[FFmpeg-devel] [RFC] av_rescale() coverity

[Timo Rothenpieler]

On 01/07/2024 22:19, Michael Niedermayer wrote:
> On Mon, Jul 01, 2024 at 08:50:24PM +0200, Timo Rothenpieler wrote:
>> On 01.07.2024 15:39, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> coverity seems to have started to do a new thing. Namely if theres a
>>> return statement it assumes it can independant of everything occurr
>>>
>>> an example would be av_rescale() which on overflow returns INT64_MIN
>>>
>>> also with the right flags av_rescale() will pass INT64_MIN and INT64_MAX through
>>> from the input
>>>
>>> So coverity since a few days seems to treat every av_rescale() call as if it returns
>>> INT64_MIN and INT64_MAX. coverity doesnt care if that return statement is reachable or
>>> if the flags even include the execution path.
>>>
>>> An example is this:
>>>               AVRational time_base_q = AV_TIME_BASE_Q;
>>>               int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate));
>>>               ds->next_dts = av_rescale_q(next_dts + 1, av_inv_q(ist->framerate), time_base_q);
>>>
>>> Here coverity as a initial statement claims next_dts is INT64_MAX
>>> and next_dts + 1 would overflow
>>>
>>>
>>>       8. function_return: Function av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)) returns 9223372036854775807.
>>>               9. known_value_assign: next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)), its value is now 9223372036854775807.
>>>       331            int64_t next_dts = av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate));
>>>
>>>       CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLOW)
>>>       10. overflow_const: Expression next_dts + 1LL, which is equal to -9223372036854775808, where next_dts is known to be equal to 9223372036854775807, overflows the type that receives it, a signed integer 64 bits wide.
>>>
>>>
>>> another example is this:
>>>
>>>       #define AV_TIME_BASE            1000000
>>>       pts = av_rescale(ds->dts, 1000000, AV_TIME_BASE);
>>>
>>> coverity hallucinates pts as a tainted negative number here nothing says anything about
>>> the input ds->dts (and thats what would matter)
>>>
>>> In the past coverity provided a detailed list of steps on how a
>>> case is reached. One could then check these assumtions and mark things
>>> as false positive when one assumtion is wrong. (coverity was most of the time
>>> wrong)
>>>
>>> Now coverity just hallucinates claims out of the blue without any
>>> explanation how that can happen.
>>>
>>> Iam a bit at a loss how to deal with this and also why exactly this
>>> new behavior appeared.
>>>
>>> Has anyone changed any setting or anything in coverity ?
>>>
>>> The number of issues shot up to over 400 on the 22th june
>>> "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan."
>>
>> Do you mean May?
>> Cause that's when I enabled also giving a Windows-Build to Coverity:
>> https://github.com/FFmpeg/FFmpeg-Coverity/commit/3116e6960406f01f96d934516216bb3b402122fc
>>
>> Before that, only Linux was analyzed.
> 
> no the 194 appeared in june
> 
> I did saw some other spike of issues appear month? earlier or so but these seemed
> mostly old issues that where detected prior already.
> and i dont see it in teh numbers coverity mails me
> 
> Only other spike i can find in the numbers was 11 feb 2024
> 103 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Scan.
> 
> thx
> 
> [...]

I do wonder if sending them two builds at once like this is not supported?
I found examples of doing it like this though, they even document how to 
combine report generated on separate hosts. So it really should be possible.
Cause I think the huge jumps up and down in detection started only after 
adding the mingw builds.