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 C97EA4B1EB for ; Mon, 1 Jul 2024 21:00:13 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id EA94968D657; Tue, 2 Jul 2024 00:00:09 +0300 (EEST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id D014768D871 for ; Tue, 2 Jul 2024 00:00:01 +0300 (EEST) Received: by mail.gandi.net (Postfix) with ESMTPSA id 16C3920003 for ; Mon, 1 Jul 2024 21:00:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=niedermayer.cc; s=gm1; t=1719867601; 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=ra3nUA6Zod6cHT78e2HSZEgPgy36JRwiXn7qjEIxmfk=; b=pBMUnx2nC2Pwm911iiI0xFXhwRbCPIKRs+TidGSVjyeY85KpimqJLhaY0FtVwdXDJNhsdl FPa5QFniesKm1ikdFGGuQojFQmYU7CrFV7bk7NXvhGt0RP0PQOSY0zEK+uVRorFx7ksprR JIWpPCskw+JSa8fmzn/QLR+3hHoZRQUr0If7sCkDgfdUaTNCPzpno9Lp8y9KJ14oSQQWTs pmn4O5pUtKq6NjLl/lCDfjTjPEpDRByphAqaKt6Ap1UBe2zu6D+dlUcPygid50kFovAnMd EmiQW0XQh+vNa9sZakyyBK6UmrXhUEL6lK5DcnyWiLO+fqPf1sdy3PwshjMQeQ== Date: Mon, 1 Jul 2024 23:00:00 +0200 From: Michael Niedermayer To: FFmpeg development discussions and patches Message-ID: <20240701210000.GJ4991@pb2> References: <20240701133923.GF4991@pb2> <2e923434-4c36-4921-b728-acdc4dd39233@rothenpieler.org> <20240701201931.GI4991@pb2> MIME-Version: 1.0 In-Reply-To: <20240701201931.GI4991@pb2> 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="===============5392428762479999326==" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: --===============5392428762479999326== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ensexbfp9Ul6anXl" Content-Disposition: inline --ensexbfp9Ul6anXl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 > > >=20 > > > coverity seems to have started to do a new thing. Namely if theres a > > > return statement it assumes it can independant of everything occurr > > >=20 > > > an example would be av_rescale() which on overflow returns INT64_MIN > > >=20 > > > also with the right flags av_rescale() will pass INT64_MIN and INT64_= MAX through > > > from the input > > >=20 > > > So coverity since a few days seems to treat every av_rescale() call a= s if it returns > > > INT64_MIN and INT64_MAX. coverity doesnt care if that return statemen= t is reachable or > > > if the flags even include the execution path. > > >=20 > > > 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_bas= e_q, av_inv_q(ist->framerate)); > > > ds->next_dts =3D av_rescale_q(next_dts + 1, av_inv_q(ist= ->framerate), time_base_q); > > >=20 > > > Here coverity as a initial statement claims next_dts is INT64_MAX > > > and next_dts + 1 would overflow > > >=20 > > >=20 > > > 8. function_return: Function av_rescale_q(ds->next_dts, time_bas= e_q, av_inv_q(ist->framerate)) returns 9223372036854775807. > > > 9. known_value_assign: next_dts =3D av_rescale_q(ds->nex= t_dts, time_base_q, av_inv_q(ist->framerate)), its value is now 92233720368= 54775807. > > > 331 int64_t next_dts =3D av_rescale_q(ds->next_dts, t= ime_base_q, av_inv_q(ist->framerate)); > > >=20 > > > 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 9223372036854= 775807, overflows the type that receives it, a signed integer 64 bits wide. > > >=20 > > >=20 > > > another example is this: > > >=20 > > > #define AV_TIME_BASE 1000000 > > > pts =3D av_rescale(ds->dts, 1000000, AV_TIME_BASE); > > >=20 > > > coverity hallucinates pts as a tainted negative number here nothing s= ays anything about > > > the input ds->dts (and thats what would matter) > > >=20 > > > 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) > > >=20 > > > Now coverity just hallucinates claims out of the blue without any > > > explanation how that can happen. > > >=20 > > > Iam a bit at a loss how to deal with this and also why exactly this > > > new behavior appeared. > > >=20 > > > Has anyone changed any setting or anything in coverity ? > > >=20 > > > The number of issues shot up to over 400 on the 22th june > > > "194 new defect(s) introduced to FFmpeg/FFmpeg found with Coverity Sc= an." > >=20 > > 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 > >=20 > > Before that, only Linux was analyzed. >=20 > no the 194 appeared in june >=20 > I did saw some other spike of issues appear month? earlier or so but thes= e seemed > mostly old issues that where detected prior already. > and i dont see it in teh numbers coverity mails me >=20 > 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. The mail for the windows spike went to my old email address from gmx, was misidentified as spam and deleted by gmx. gmx "recently" forced their broken spam detection to be enabled even when explicitly disabled by the customer. One has to download the mails from a specific folder on their IMAP server 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 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin --ensexbfp9Ul6anXl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iFwEABEKAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCZoMYzAAKCRBhHseHBAsP q3zWAJ0dCrMg287uo8Ed/PNeWOAtpf0LlQCTBE9MDgLfQ7h1yBDXNMoue0rOmQ== =oWb3 -----END PGP SIGNATURE----- --ensexbfp9Ul6anXl-- --===============5392428762479999326== 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". --===============5392428762479999326==--