From: Michael Niedermayer <michael@niedermayer.cc>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [RFC] av_rescale() coverity
Date: Mon, 1 Jul 2024 22:19:31 +0200
Message-ID: <20240701201931.GI4991@pb2> (raw)
In-Reply-To: <2e923434-4c36-4921-b728-acdc4dd39233@rothenpieler.org>
[-- Attachment #1.1: Type: text/plain, Size: 3641 bytes --]
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
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
[-- Attachment #2: Type: text/plain, Size: 251 bytes --]
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
next prev parent reply other threads:[~2024-07-01 20:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-01 13:39 Michael Niedermayer
2024-07-01 18:07 ` Michael Niedermayer
2024-07-01 18:50 ` Timo Rothenpieler
2024-07-01 20:19 ` Michael Niedermayer [this message]
2024-07-01 21:00 ` Michael Niedermayer
2024-07-02 4:51 ` Vittorio Giovara
2024-07-02 18:02 ` Michael Niedermayer
2024-07-02 12:36 ` Timo Rothenpieler
2024-07-02 22:27 ` Michael Niedermayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240701201931.GI4991@pb2 \
--to=michael@niedermayer.cc \
--cc=ffmpeg-devel@ffmpeg.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This inbox may be cloned and mirrored by anyone:
git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
ffmpegdev@gitmailbox.com
public-inbox-index ffmpegdev
Example config snippet for mirrors.
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git