Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.13] gh-120161: Fix a Crash in the _datetime Module (gh-120182) #120518

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

miss-islington
Copy link
Contributor

@miss-islington miss-islington commented Jun 14, 2024

In gh-120009 I used an atexit hook to finalize the _datetime module's static types at interpreter shutdown. However, atexit hooks are executed very early in finalization, which is a problem in the few cases where a subclass of one of those static types is still alive until the final GC collection. The static builtin types don't have this probably because they are finalized toward the end, after the final GC collection. To avoid the problem for _datetime, I have applied a similar approach here.

Also, credit goes to @mgorny and @neonene for the new tests.

FYI, I would have liked to take a slightly cleaner approach with managed static types, but wanted to get a smaller fix in first for the sake of backporting. I'll circle back to the cleaner approach with a future change on the main branch.
(cherry picked from commit b2e71ff)

Co-authored-by: Eric Snow ericsnowcurrently@gmail.com

In pythongh-120009 I used an atexit hook to finalize the _datetime module's static types at interpreter shutdown.  However, atexit hooks are executed very early in finalization, which is a problem in the few cases where a subclass of one of those static types is still alive until the final GC collection.  The static builtin types don't have this probably because they are finalized toward the end, after the final GC collection.  To avoid the problem for _datetime, I have applied a similar approach here.

Also, credit goes to @mgorny and @neonene for the new tests.

FYI, I would have liked to take a slightly cleaner approach with managed static types, but wanted to get a smaller fix in first for the sake of backporting.  I'll circle back to the cleaner approach with a future change on the main branch.
(cherry picked from commit b2e71ff)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 FreeBSD14 3.13 has failed when building commit 18ea22a.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/all/#builders/1481/builds/197) and take a look at the build logs.
  4. Check if the failure is related to this commit (18ea22a) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/all/#builders/1481/builds/197

Failed tests:

  • test_interpreters

Summary of the results of the build (if available):

==

Click to see traceback logs
remote: Enumerating objects: 36, done.        
remote: Counting objects:   2% (1/36)        
remote: Counting objects:   5% (2/36)        
remote: Counting objects:   8% (3/36)        
remote: Counting objects:  11% (4/36)        
remote: Counting objects:  13% (5/36)        
remote: Counting objects:  16% (6/36)        
remote: Counting objects:  19% (7/36)        
remote: Counting objects:  22% (8/36)        
remote: Counting objects:  25% (9/36)        
remote: Counting objects:  27% (10/36)        
remote: Counting objects:  30% (11/36)        
remote: Counting objects:  33% (12/36)        
remote: Counting objects:  36% (13/36)        
remote: Counting objects:  38% (14/36)        
remote: Counting objects:  41% (15/36)        
remote: Counting objects:  44% (16/36)        
remote: Counting objects:  47% (17/36)        
remote: Counting objects:  50% (18/36)        
remote: Counting objects:  52% (19/36)        
remote: Counting objects:  55% (20/36)        
remote: Counting objects:  58% (21/36)        
remote: Counting objects:  61% (22/36)        
remote: Counting objects:  63% (23/36)        
remote: Counting objects:  66% (24/36)        
remote: Counting objects:  69% (25/36)        
remote: Counting objects:  72% (26/36)        
remote: Counting objects:  75% (27/36)        
remote: Counting objects:  77% (28/36)        
remote: Counting objects:  80% (29/36)        
remote: Counting objects:  83% (30/36)        
remote: Counting objects:  86% (31/36)        
remote: Counting objects:  88% (32/36)        
remote: Counting objects:  91% (33/36)        
remote: Counting objects:  94% (34/36)        
remote: Counting objects:  97% (35/36)        
remote: Counting objects: 100% (36/36)        
remote: Counting objects: 100% (36/36), done.        
remote: Compressing objects:  25% (1/4)        
remote: Compressing objects:  50% (2/4)        
remote: Compressing objects:  75% (3/4)        
remote: Compressing objects: 100% (4/4)        
remote: Compressing objects: 100% (4/4), done.        
remote: Total 19 (delta 17), reused 16 (delta 15), pack-reused 0        
From https://github.com/python/cpython
 * branch                  3.13       -> FETCH_HEAD
Note: switching to '18ea22a8306b5746da74d83a9db00dcc390bf092'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 18ea22a830 [3.13] gh-120161: Fix a Crash in the _datetime Module (gh-120518)
Switched to and reset branch '3.13'

configure: WARNING: no system libmpdecimal found; falling back to bundled libmpdecimal (deprecated and scheduled for removal in Python 3.15)
configure: WARNING: pkg-config is missing. Some dependencies may not be detected correctly.

@ericsnowcurrently
Copy link
Member

I'm looking into the buildbot failures. See #120182 (comment).

@ericsnowcurrently
Copy link
Member

See gh-120524.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants