Recursively calling makepasv() finally leads to core dumped.

BPO	46211

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2021-12-31.05:45:05.680>
labels = ['3.10', 'library', '3.9', 'type-crash', '3.11']
title = 'Recursively calling makepasv() finally leads to core dumped.'
updated_at = <Date 2021-12-31.05:45:05.680>
user = 'https://bugs.python.org/xxm'

bugs.python.org fields:

activity = <Date 2021-12-31.05:45:05.680>
actor = 'xxm'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2021-12-31.05:45:05.680>
creator = 'xxm'
dependencies = []
files = []
hgrepos = []
issue_num = 46211
keywords = []
message_count = 1.0
messages = ['409408']
nosy_count = 1.0
nosy_names = ['xxm']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue46211'
versions = ['Python 3.9', 'Python 3.10', 'Python 3.11']

Linked PRs

gh-90369: change test server threads to joinable #135560

See the following 'test.py', we call client.makepasv() in socket, and then create_connection. Recursively calling makepasv() finally leads to core dumped.

System: Python 3.10.1, 3.11.0a3 ,master on Ubuntu 18.04

Reproduce step:

executing "python test.py"
If only TimeoutError is observed, just executing this code again. Maybe after 4 or 5 times, this program crashes Python interpreter.

test.py
===============================================

import socket
from test.test_ftplib import TestFTPClass,TIMEOUT

def test_makepasv():
    host, port = TestFTPClass.client.makepasv()
    conn = socket.create_connection((test_makepasv(), host), timeout=TIMEOUT)
    conn.close()

===============================================

Error Message:
---------------------------------------------------

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/asyncore.py", line 90, in read
    obj.handle_read_event()
    ^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/asyncore.py", line 427, in handle_read_event
Traceback (most recent call last):
.....
  File "/home/xxm/Desktop/compilers/cpython-main12-31/Lib/test/test_ftplib.py", line 298, in run
    return self._sock.recv_into(b)
           ^^^^^^^^^^^^^^^^^^^^^^^
TimeoutError: timed out
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x0000556df3cfbe30)

Current thread 0x00007fb82ce69080 (most recent call first):
<no Python frame>

Extension modules: _testcapi (total: 1)
Aborted (core dumped)
-----------------------------------------------------

@ZeroIntensity

The reproduction no longer works on current HEAD. However, it is recursively opening FTP connections until it either runs out of FDs or the stack overflows. The crash is coming from a daemon thread started by the test code, which is inherently racy with shutdown.

Since test framework is only meant for internal use and it isn't being used correctly, I'd normally suggest just closing this. However, IIUC, we do want to eliminate daemon threads and their raciness where we can (right @ZeroIntensity?).

As it turns out the threads were originally joinable and were daemonized in 529525f for #7079, but the code that joined them was left intact. The commit message doesn't mention the change and it looks like it was perhaps a mistake. @tiran, do you recall anything about it?

There was another thread in test_poplib which was daemonized in the same commit and which can also be made joinable safely.

pythongh-90369: change test server threads to joinable

@ZeroIntensity

However, IIUC, we do want to eliminate daemon threads and their raciness where we can (right @ZeroIntensity?).

I personally don't like daemon threads, but they're not necessarily an issue themself. See this section in PEP 788. Ideally, we'll solve the raciness in C code via interpreter references, not by removing usage of daemon threads from Python code.

Closing per discussion in GH-135560

Navigation Menu

Repository navigation

Recursively calling makepasv() finally leads to core dumped. #90369

Linked PRs

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Recursively calling makepasv() finally leads to core dumped. #90369

Description

Linked PRs

Activity

xxm commented on Dec 31, 2021

duaneg commented on Jun 16, 2025

ZeroIntensity commented on Jun 16, 2025

ZeroIntensity commented on Jun 23, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions