From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id B6CD94B0CE for ; Tue, 2 Jul 2024 18:02:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id BD04668D933; Tue, 2 Jul 2024 21:02:11 +0300 (EEST) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 4562E68D7AA for ; Tue, 2 Jul 2024 21:02:05 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id A579BFF806 for ; Tue, 2 Jul 2024 18:02:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1719943324; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=1MNl+1EOeqai/ZZHA5ASe1uwksZeOLPPHREp2qdxJTE=; b=Cki5nfcRaJfcR/+rPtJ9JghfKsZq46Lp2noltYcV08QpVSvRsFP0HEirRjwVZ/cNwxOtgZ GBRvZXjZ4l+uPDSzwrKhdq1+QQdXMvImcK8u+XtwhSWSqTSbo3JtMQAkdfrq8Oj/tEXBq+ A0HCGcW6NcJ69M3id2m39nghpDH+3jzQuXSZqdaD6tLHkea/f3+Gyl9R5Zr7pucm+lYeA8 +N0/Ar6YvkiEgQfUEhStT+B1GxDF21kXzGF456qjm+CAevZ7iT28oDMJM6PMlz5CET3qhV /ri1xSU69niCGx4bZUNBYFP2XFFvFEqHJ3eHVdJ3KzJ6CrIkDcT2FAxAyBq28A== Date: Tue, 2 Jul 2024 20:02:03 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240702180203.GP4991@pb2> References: <20240701133923.GF4991@pb2> <2e923434-4c36-4921-b728-acdc4dd39233@rothenpieler.org> <20240701201931.GI4991@pb2> <20240701210000.GJ4991@pb2> MIME-Version: 1.0 In-Reply-To: X-GND-Sasl: michael@niedermayer.cc Subject: Re: [FFmpeg-devel] [RFC] av_rescale() coverity X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: multipart/mixed; boundary="===============2909648430148273200==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============2909648430148273200== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H25ow1gEc5p8sQPX" Content-Disposition: inline --H25ow1gEc5p8sQPX Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 02, 2024 at 06:51:16AM +0200, Vittorio Giovara wrote: > On Mon, Jul 1, 2024 at 11:00=E2=80=AFPM Michael Niedermayer > wrote: >=20 > > On Mon, Jul 01, 2024 at 10:19:31PM +0200, 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 there= s a > > > > > return statement it assumes it can independant of everything occu= rr > > > > > > > > > > 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() ca= ll > > 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 =3D AV_TIME_BASE_Q; > > > > > int64_t next_dts =3D av_rescale_q(ds->next_dts, > > time_base_q, av_inv_q(ist->framerate)); > > > > > ds->next_dts =3D 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 =3D > > av_rescale_q(ds->next_dts, time_base_q, av_inv_q(ist->framerate)), its > > value is now 9223372036854775807. > > > > > 331 int64_t next_dts =3D av_rescale_q(ds->next_dt= s, > > time_base_q, av_inv_q(ist->framerate)); > > > > > > > > > > CID 1604545: (#1 of 1): Overflowed constant (INTEGER_OVERFLO= W) > > > > > 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 inte= ger > > 64 bits wide. > > > > > > > > > > > > > > > another example is this: > > > > > > > > > > #define AV_TIME_BASE 1000000 > > > > > pts =3D av_rescale(ds->dts, 1000000, AV_TIME_BASE); > > > > > > > > > > coverity hallucinates pts as a tainted negative number here nothi= ng > > 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 th= is > > > > > 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/3116e6960406f01f96d934= 516216bb3b402122fc > > > > > > > > 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 Sca= n. > > > > The mail for the windows spike went to my old email address from gmx, w= as > > misidentified as spam and deleted by gmx. gmx "recently" forced their > > broken > > spam detection to be enabled even when explicitly disabled by the custo= mer. > > One has to download the mails from a specific folder on their IMAP serv= er > > within a month it seems. Which i didnt because i had their whole broken > > spam detection disabled > > > > Its not imprtant but if someone has all the coverity mails, a list of > > new and fixed bugs on each run would be interresting > > > > thx >=20 >=20 > Have you tried getting in touch with coverity support about this new > behavior? i will if adjusting our modelling file doesnt fix it. It seems 56 issues disappeared on the last run and 3 new av_rescale() issues appeared that look more sane, but i did not yet had the time to really investigate how things look now thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator --H25ow1gEc5p8sQPX Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZoRAlQAKCRBhHseHBAsP q4THAJ9+x2GSwCNxBHEAJrd1DPDrDZ+oxQCeKvKJ6+AKrt6/nGH6i+LauCrecLA= =w1Ji -----END PGP SIGNATURE----- --H25ow1gEc5p8sQPX-- --===============2909648430148273200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ 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". --===============2909648430148273200==--