From: Eric Feng <ef2648@columbia.edu>
To: David Malcolm <dmalcolm@redhat.com>
Cc: gcc@gcc.gnu.org
Subject: Re: Update on CPython Extension Module -fanalyzer plugin development
Date: Thu, 24 Aug 2023 10:45:19 -0400 [thread overview]
Message-ID: <CANGHATU9wgB8dM3isRwjpGZAq2xzTXQ+_Qw=b3GCrugJYZrzEg@mail.gmail.com> (raw)
In-Reply-To: <775fd332b3b4f6b4571f49c276a546423554a9b9.camel@redhat.com>
On Wed, Aug 23, 2023 at 7:16 PM David Malcolm <dmalcolm@redhat.com> wrote:
>
> On Wed, 2023-08-23 at 17:15 -0400, Eric Feng wrote:
> > On Mon, Aug 21, 2023 at 11:04 AM David Malcolm <dmalcolm@redhat.com>
> > wrote:
> > >
> > > On Mon, 2023-08-21 at 10:05 -0400, Eric Feng wrote:
> > > > Hi Dave,
> > > >
> > > > Just wanted to give you and everyone else a short update on how
> > > > reference count checking is going — we can now observe the refcnt
> > > > diagnostic being emitted:
> > > >
> > > > rc3.c:22:10: warning: REF COUNT PROBLEM
> > > > 22 | return list;
> > > > | ^~~~
> > > > ‘create_py_object’: events 1-4
> > > > |
> > > > | 4 | PyObject* item = PyLong_FromLong(3);
> > > > | | ^~~~~~~~~~~~~~~~~~
> > > > | | |
> > > > | | (1) when ‘PyLong_FromLong’
> > > > succeeds
> > > > | 5 | PyObject* list = PyList_New(1);
> > > > | | ~~~~~~~~~~~~~
> > > > | | |
> > > > | | (2) when ‘PyList_New’ succeeds
> > > > |......
> > > > | 14 | PyList_Append(list, item);
> > > > | | ~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > | | |
> > > > | | (3) when ‘PyList_Append’ fails
> > > > |......
> > > > | 22 | return list;
> > > > | | ~~~~
> > > > | | |
> > > > | | (4) here
> > > > |
> > > >
> > > > I will fix up and refactor the logic for counting the actual ref
> > > > count
> > > > before coming back and refining the diagnostic to give much more
> > > > detailed information.
> > >
> > > Excellent! Thanks for the update.
> > >
> > > Dave
> > >
> >
> > Hi Dave,
> >
> > I've since fixed up the logic to count the actual reference counts of
> > the PyObject* instances.
>
> Sounds promising.
>
> > Now, I'm contemplating the specific
> > diagnostics we'd want to issue and the appropriate conditions for
> > emitting them. With this in mind, I wanted to check in with you on
> > the
> > appropriate approach:
> >
> > To start, I'm adopting the same assumptions as cpychecker for
> > functions returning a PyObject*. That is, I'm operating under the
> > premise that by default such functions return a new reference upon
> > success rather than, for example, a borrowed reference (which we can
> > tackle later on). Given this, it's my understanding that the
> > reference
> > count of the returned object should be 1 if the object is newly
> > created within the function body and incremented by 1 from what it
> > was
> > previously if not newly created (e.g passed in as an argument).
> > Furthermore, the reference count for any PyObject* instances created
> > within the function should be 0, barring situations where we're
> > returning a collection, like a list, that includes references to
> > these
> > objects.
> >
> > Let me know what you think; thanks!
>
> This sounds like a good approach for v1 of the implementation.
>
> It's probably best to focus on getting a simple version of the patch
> into trunk, and leave any polish of it to followups.
>
> In terms of deciding what the reference count of a returned PyObject *
> ought to be, cpychecker had logic to try to detect callbacks used by
> PyMethodDef tables, so that e.g. in:
>
> static PyMethodDef widget_methods[] = {
> {"display",
> (PyCFunction)widget_display,
> (METH_VARARGS | METH_KEYWORDS), /* ml_flags */
> NULL},
>
> {NULL, NULL, 0, NULL} /* terminator */
> };
>
> ...we'd know that the callback function "widget_display" follows the
> standard rules for a PyCFunction (e.g. returns a new reference).
>
> But that's for later; don't bother trying to implement that until we
> have the basics working.
I see; sounds good!
>
> Is it worth posting a work-in-progress patch of what you have so far?
> (you don't need to bother with a ChangeLog for that)
Will post a WIP soon. Thanks!
>
> Dave
>
next prev parent reply other threads:[~2023-08-24 14:45 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 4:49 Update and Questions " Eric Feng
2023-07-25 14:41 ` David Malcolm
2023-07-27 22:13 ` Eric Feng
2023-07-27 22:35 ` David Malcolm
2023-07-30 17:52 ` Eric Feng
2023-07-30 23:44 ` David Malcolm
2023-08-01 13:57 ` Eric Feng
2023-08-01 17:06 ` David Malcolm
2023-08-04 15:02 ` Eric Feng
2023-08-04 15:39 ` David Malcolm
2023-08-04 20:48 ` Eric Feng
2023-08-04 22:42 ` David Malcolm
2023-08-04 22:46 ` David Malcolm
2023-08-07 18:31 ` Eric Feng
2023-08-07 23:16 ` David Malcolm
2023-08-08 16:51 ` [PATCH] WIP for dg-require-python-h [PR107646] Eric Feng
2023-08-08 18:08 ` David Malcolm
2023-08-08 18:51 ` David Malcolm
2023-08-09 19:22 ` [PATCH v2] analyzer: More features for CPython analyzer plugin [PR107646] Eric Feng
2023-08-09 21:36 ` David Malcolm
2023-08-11 17:47 ` [COMMITTED] " Eric Feng
2023-08-11 20:23 ` Eric Feng
2023-08-16 19:17 ` Update on CPython Extension Module -fanalyzer plugin development Eric Feng
2023-08-16 21:28 ` David Malcolm
2023-08-17 1:47 ` Eric Feng
2023-08-21 14:05 ` Eric Feng
2023-08-21 15:04 ` David Malcolm
2023-08-23 21:15 ` Eric Feng
2023-08-23 23:16 ` David Malcolm
2023-08-24 14:45 ` Eric Feng [this message]
2023-08-25 12:50 ` Eric Feng
2023-08-25 19:50 ` David Malcolm
2023-08-29 4:31 ` [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646] Eric Feng
2023-08-29 4:35 ` Eric Feng
2023-08-29 17:28 ` Eric Feng
2023-08-29 21:14 ` David Malcolm
2023-08-30 22:15 ` Eric Feng
2023-08-31 17:01 ` David Malcolm
2023-08-31 19:09 ` Eric Feng
2023-08-31 20:19 ` David Malcolm
2023-09-01 1:25 ` Eric Feng
2023-09-01 11:57 ` David Malcolm
2023-09-05 2:13 ` [PATCH] analyzer: implement symbolic value support for CPython plugin's refcnt checker [PR107646] Eric Feng
2023-09-07 17:28 ` David Malcolm
2023-09-11 2:12 ` Eric Feng
2023-09-11 19:00 ` David Malcolm
2023-08-29 21:08 ` [PATCH] analyzer: implement reference count checking for CPython plugin [PR107646] David Malcolm
2023-09-01 2:49 ` Hans-Peter Nilsson
2023-09-01 14:51 ` David Malcolm
2023-09-01 21:07 ` Eric Feng
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='CANGHATU9wgB8dM3isRwjpGZAq2xzTXQ+_Qw=b3GCrugJYZrzEg@mail.gmail.com' \
--to=ef2648@columbia.edu \
--cc=dmalcolm@redhat.com \
--cc=gcc@gcc.gnu.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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).