public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Feng <ef2648@columbia.edu>
To: Nada Elsayed <nadaelsayed163@gmail.com>
Cc: gcc@gcc.gnu.org, David Malcolm <dmalcolm@redhat.com>
Subject: Re: GSoC Timeline Review
Date: Wed, 3 Apr 2024 22:38:34 -0400	[thread overview]
Message-ID: <CANGHATV_cJqre2KvUC7XP=2OHe7bUW-L0ATnO3hsHB0OTzXaRQ@mail.gmail.com> (raw)
In-Reply-To: <ri6a5mb3k92.fsf@virgil.suse.cz>

[-- Attachment #1: Type: text/plain, Size: 5872 bytes --]

Hi Nada,

Apologies for not being able to reply earlier as well. I’m glad to hear
you’re interested in continuing this project! There is still a lot of work
to be done — my work from last summer is in a very prototype stage. As
David mentioned, familiarizing myself with the analyzer took some time, but
I'm confident you’ll be able to make quicker progress if you're more
experienced. If you’re interested in continuing to work on the reference
count checking aspect of the project in a similar direction to what I was
doing, this bugzilla post might be helpful:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107646. Specifically, David
and I discussed the challenge of scaling the implementation effectively,
particularly when tracking the behavior of every API entrypoint through
subclassing of known functions, and how we might reduce some of this effort
with function attributes. Moreover, you might also be interested in
exploring the work presented by Xutong Ma et al. at ASE 2023 late last
summer, titled “Detecting Memory Errors in Python Native Code by Tracking
Object Lifecycle with Reference Count,” as well as the works it was
compared against, if you’re interested in exploring alternative approaches.
Overall, I hope you find the experience as enriching as I did should you
work on this project! Please feel free to reach out with any questions and
I’ll be more than happy to help where I can.

Best,
Eric


On Tue, Apr 2, 2024 at 10:35 AM Martin Jambor <mjambor@suse.cz> wrote:

> Hello,
>
> On Sat, Mar 30 2024, Nada Elsayed via Gcc wrote:
> > I think that I didn't fully understand the project, so I read more and
> > updated the Timeline Suggestion.
>
> Sorry that we were for not being able to respond sooner, Easter got into
> way in an unfortunate way.  I do not know much about Cython or static
> analysis (so I would not be able to give much advice about improvements
> to the time-line), but can confirm we have received your application.
>
> Thanks a lot.
>
> Martin
>
> >
> > Suggested Timeline:
> >
> >    -
> >
> >    May 1-26:
> >    -
> >
> >       Explore Cython modules and try more realistic codes to see how it
> >       translates Python to c/c++.
> >       -
> >
> >       Know more about entry-points that Cython uses.
> >       -
> >
> >       Understand common bugs that happen when converting Python to c/c++.
> >
> >
> >
> >    -
> >
> >    Explore static analysis tool for CPython Extension code -which is
> >    written in Python- and try this analyzer to understand the bugs in
> >    translated Python code fully.
> >    -
> >
> >    Know how we can emit warnings and errors.
> >
> >
> >
> >    -
> >
> >    Debug the codebase to grasp its structure and potential areas for
> >    improvement.
> >
> >
> >    -
> >
> >    Weeks 1-2:
> >    -
> >
> >       Understand more about reference counting verification.
> >       -
> >
> >       Develop verifying reference counts for PyObjects passed as
> parameters.
> >       -
> >
> >    Weeks 3-4:
> >    -
> >
> >       Begin to investigate Error Handling Checking.
> >       -
> >
> >       Understand how the Static Analysis tool does Error Handling
> checking.
> >       -
> >
> >       Implement these checks in the plugin.
> >       -
> >
> >    Weeks 5-7:
> >    -
> >
> >       Begin to investigate Exception Handling Checking.
> >       -
> >
> >       Understand how the Static Analysis tool does Exception Handling
> >       checking.
> >       -
> >
> >       Implement these checks in the plugin.
> >       -
> >
> >    Weeks 8-11
> >    -
> >
> >       Begin to investigate Format String Checking.
> >       -
> >
> >       Understand how the Static Analysis tool does Format String
> Checking.
> >       -
> >
> >       Implement these checks in the plugin.
> >       -
> >
> >    Week 12
> >    -
> >
> >       Writing the GSoC wrapping-up document.
> >
> >
> > ‫في الأربعاء، 27 مارس 2024 في 2:31 ص تمت كتابة ما يلي بواسطة ‪Nada
> > Elsayed‬‏ <‪nadaelsayed163@gmail.com‬‏>:‬
> >
> >> Greetings All,
> >> Hope this email finds you well.
> >> I am interested in "Extend the plugin to add checking for usage of the
> >> CPython API" project. First of all, I built the library, and now I am
> >> trying to debug it. Then, I also used Cpython in 3 demos to understand
> how
> >> it works. Finally, I read the uploaded patch comments to understand the
> >> codebase and file structure.
> >>
> >> I was wondering if you could review my suggested timeline?
> >> suggested Timeline:
> >>
> >>    -
> >>
> >>    May 1-26:
> >>    -
> >>
> >>       Explore Cython modules, emphasizing entry-points and bug
> >>       identification.
> >>       -
> >>
> >>       Study analyzers, particularly cpy-analyzer, to enhance
> >>       understanding.
> >>       -
> >>
> >>       Debug the codebase to grasp its structure and potential areas for
> >>       improvement.
> >>       -
> >>
> >>       Focus investigation on "errors in GIL handling" and "tp_traverse
> >>       errors".
> >>       -
> >>
> >>    Weeks 1-6:
> >>    -
> >>
> >>       Investigate GIL (Global Interpreter Lock) errors extensively.
> >>       -
> >>
> >>       Engage in discussions and develop viable solutions to address
> >>       identified issues.
> >>
> >>
> >>
> >>    -
> >>
> >>    Weeks 7-12:
> >>    -
> >>
> >>       Gain insight into the functioning of the Garbage Collector.
> >>       -
> >>
> >>       Implement checks to mitigate traverse errors effectively.
> >>       -
> >>
> >>       Ensure robust error handling mechanisms are in place through
> >>       thorough study and practical implementation.
> >>
> >>
>

  reply	other threads:[~2024-04-04  2:38 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-02 14:35 Martin Jambor
2024-04-04  2:38 ` Eric Feng [this message]
  -- strict thread matches above, loose matches on Subject: below --
2024-03-27  0:31 Nada Elsayed
2024-03-30 11:54 ` Nada Elsayed
2024-04-02 14:06   ` David Malcolm
2024-04-02 14:09     ` David Malcolm

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='CANGHATV_cJqre2KvUC7XP=2OHe7bUW-L0ATnO3hsHB0OTzXaRQ@mail.gmail.com' \
    --to=ef2648@columbia.edu \
    --cc=dmalcolm@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=nadaelsayed163@gmail.com \
    /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).