From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) by sourceware.org (Postfix) with ESMTPS id 1E5393858D3C for ; Wed, 29 Mar 2023 22:50:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1E5393858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pf1-x42d.google.com with SMTP id fd25so11326855pfb.1 for ; Wed, 29 Mar 2023 15:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680130254; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=fQFInfnqYcC0VSh2iuJt9GRzV/b1G0vYRNjC37QRI/E=; b=XRPsYi1U4lvW87Rn+yPqxnKkNPTi2Vq4GM4hl8sUafy2OsXqa5uR5xN5ey051UFnaK Y3Fdq3h1Gy9vd5KjwRyBM/erShLkYsXOQE/ZXLxEyjcnwlzVdATtJxdALXKkcZ/1rYrU gr6iT++T+2diZ/HcmB8z0feR31lFEzYyYaX+k6oLlEglAedpdaWpZS9kdleVsCJmXwSC V7zFiLYrzkSAHMT4hSH80H2/hZ/9HG7u1BK3nMuI+k3tExc4SNmW7fTpgS6j8iDgc4CA ujuqaqm9oblsoTAru4PqHfPXHkmsvOmrHxB4U5c/ZfIAkvFO6oSE/JR/wz9Nh+hWCpX+ 62xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680130254; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=fQFInfnqYcC0VSh2iuJt9GRzV/b1G0vYRNjC37QRI/E=; b=aXK+fw8m5CLemjT5MnhTVzwllM66oZoEIR8yxCiY8bPIWl07hnR2D3zUBflb/MOpIO E5i6tbxAPMzpZWz9Yml3czvdwTqw55NwLj0bM5TIi5iuoDrJL4Dfs7VhPrFzjtWJaf4Y C89p9tjNbhx+4ED3dlYjxyS4dzta+dFVO9EmpoIz9MDM9Z6K1mM2GD2K4V8qIDolJqyV nTbXQq4WQpcS6xoZxzBcThyIhOsn0YsYtf+O1vXsNcMkWgjg3tI0jzAK0Q33fynQf1T8 wYb6A9kekbZOcYgUzIALmxADeZyyxIIfQksNlZzER4vJcWrly2WWqYXGF1/hT2xThM79 8quw== X-Gm-Message-State: AAQBX9dcpSBiDCvTaqo1TLyey+oyfP9vIDqu0nEx4ylUoHoNntSMHGTY F4/MtzbFSJC2pYDaq5gMUVo59J+pr+Fbv8GRww== X-Google-Smtp-Source: AKy350aC13TU1rbHDRUFAZ6FEzDjO6Gsc8wN6zc99VdyiLb/SMrkQYQbLtWKU7ihYjdIxeDvXkfUZMYgTWmbEHUDhQc= X-Received: by 2002:a05:6a00:24c4:b0:629:f9a2:64e6 with SMTP id d4-20020a056a0024c400b00629f9a264e6mr11010093pfv.4.1680130253835; Wed, 29 Mar 2023 15:50:53 -0700 (PDT) MIME-Version: 1.0 From: Benjamin Priour Date: Thu, 30 Mar 2023 00:50:42 +0200 Message-ID: Subject: [GSoC] A bunch of questions about sm-malloc behavior, and proposition of a GSoC subject. To: David Malcolm Cc: gcc@gcc.gnu.org Content-Type: multipart/alternative; boundary="000000000000f4d0c905f811ceb9" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000f4d0c905f811ceb9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, I've been playing around with sm-malloc on C++ samples. I've noticed double delete don't go under -Wanalyzer-double-free but within -Wanalyzer-use-after-free scope. With the reproducer ... > struct A {}; > > int main() { > A* a =3D new A(); > delete a; > delete a; > return 0; > } ... the analyzer diagnoses: build/gcc/xg++ -Bbuild/gcc -S -fanalyzer -Wanalyzer-mismatching-deallocation -Wanalyzer-use-after-free -Wanalyzer-double-free -Wanalyzer-malloc-leak double_delete_test.cpp double_delete_test.cpp: In function =E2=80=98int main()=E2=80=99: double_delete_test.cpp:7:1: warning: use after =E2=80=98delete=E2=80=99 of = =E2=80=98a=E2=80=99 [CWE-416] [-Wanalyzer-use-after-free] 7 | } | ^ =E2=80=98int main()=E2=80=99: events 1-8 | | 3 | A* a =3D new A(); | | ^ | | | | | (1) allocated here | | (2) assuming =E2=80=98operator new(8)=E2=80= =99 is non-NULL | 4 | delete a; | | ~~~~~~~~ | | | | | | | (4) ...to here | | | (5) deleted here | | (3) following =E2=80=98true=E2=80=99 branch... | 5 | delete a; | | ~~~~~~~~ | | | | | | | (7) ...to here | | (6) following =E2=80=98true=E2=80=99 branch... | 6 | return 0; | 7 | } | | ~ | | | | | (8) use after =E2=80=98delete=E2=80=99 of =E2=80=98a=E2=80=99;= deleted at (5) | double_delete_test.cpp:3:18: warning: dereference of possibly-NULL =E2=80=98operator new(8)=E2=80=99 [CWE-690] [-Wanalyzer-possible-null-deref= erence] 3 | A* a =3D new A(); | ^ =E2=80=98int main()=E2=80=99: events 1-2 | | 3 | A* a =3D new A(); | | ^ | | | | | (1) this call could return NULL | | (2) =E2=80=98operator new(8)=E2=80=99 could b= e NULL: unchecked value from (1) | Debugging read out two things: - During second call of 'on_deallocator_call' on delete, the state would be 'stop' instead of the expected 'freed' - The call to set_next_state transitions malloc instead of delete from 'nonnull' to 'freed'. I'm still trying to come up with why these two behaviors happens. By the way, in the first call to 'on_deallocator_call' on delete, the state is set to 'nonnull', which conforms to C++ behavior for new. However, a -Wanalyzer-possible-null-dereference is emitted at the expression 'new'. I haven't yet figured out why, but I'm looking into it. Another observation was in the distinction between delete and free in the case of mixing them. With 'a' being allocated with malloc: > A* a =3D (A*) malloc(sizeof(A)); > free(a); > delete a; // -Wanalyzer-use-after-free, OK, might expect warning for double free though ? but with allocation through new and inversion of free/delete > A* a =3D new A(); > delete a; > free(a); // No diagnostics at all from the analyzer, got -Wmismatched-new-delete from the front-end though. I believe this might come from a similar issue as above, but I still have to investigate on that front. I just noticed another unexpected behavior. Let's consider > struct A {int x; int y;}; > void* foo() { A* a =3D (A*) __builtin_malloc(sizeof(A)); return a; } > int main() { > A* a2 =3D (A*) __builtin_malloc(sizeof(A)); > foo(); > return 0; > } Then a -Wanalyzer-malloc-leak is correctly ensued for allocation in foo(), but none is emitted for the leak in main(), although I checked the exploded graph it is correctly marked as unchecked(free). Should I file those on bugzilla ? Also I have taken interest in PR106388 - Support for use-after-move in -fanalyzer -. The prerequisite PR106386 - Reuse libstdc++ assertions - would also be of great help in extending the support of -Wanalyzer-out-of-bounds, as we could detect out-of-bounds on vectors through __glibcxx_requires_subscript used in the definition of operator[]. I already thought about a few ideas to implement that, but I'll develop them more and try to come up with some proof of concept before sending them to you. Hopefully by tomorrow I'll update on this, I'll preferably hop to bed now haha. Do you think this could make a suitable GSoC subject ? Best, Benjamin. --000000000000f4d0c905f811ceb9--