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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
