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

bpo-44434: Don't call PyThread_exit_thread() explicitly #26758

Merged
merged 1 commit into from
Jun 21, 2021
Merged

bpo-44434: Don't call PyThread_exit_thread() explicitly #26758

merged 1 commit into from
Jun 21, 2021

Conversation

vstinner
Copy link
Member

@vstinner vstinner commented Jun 16, 2021

_thread.start_new_thread() no longer calls PyThread_exit_thread()
explicitly at the thread exit, the call was redundant.

On Linux with the glibc, pthread_cancel() loads dynamically the
libgcc_s.so.1 library. dlopen() can fail if there is no more
available file descriptor to open the file. In this case, the process
aborts with the error message:

"libgcc_s.so.1 must be installed for pthread_cancel to work"

pthread_cancel() unwinds back to the thread's wrapping function that
calls the thread entry point.

The unwind function is dynamically loaded from the libgcc_s library
since it is tightly coupled to the C compiler (GCC). The unwinder
depends on DWARF, the compiler generates DWARF, so the unwinder
belongs to the compiler.

Thanks Florian Weimer and Carlos O'Donell for their help on
investigating this issue.

https://bugs.python.org/issue44434

_thread.start_new_thread() no longer calls PyThread_exit_thread()
explicitly at the thread exit, the call was redundant.

On Linux with the glibc, pthread_cancel() loads dynamically the
libgcc_s.so.1 library. dlopen() can fail if there is no more
available file descriptor to open the file. In this case, the process
aborts with the error message:

"libgcc_s.so.1 must be installed for pthread_cancel to work"

pthread_cancel() unwinds back to the thread's wrapping function that
calls the thread entry point.

The unwind function is dynamically loaded from the libgcc_s library
since it is tightly coupled to the C compiler (GCC). The unwinder
depends on DWARF, the compiler generates DWARF, so the unwinder
belongs to the compiler.

Thanks Florian Weimer and Carlos O'Donell for their help on
investigating this issue.
@vstinner
Copy link
Member Author

cc @pablogsal @pitrou

@vstinner
Copy link
Member Author

Copy link
Contributor

@erlend-aasland erlend-aasland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, as far as I can see.

@vstinner vstinner merged commit 45a78f9 into python:main Jun 21, 2021
@miss-islington
Copy link
Contributor

Thanks @vstinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.9.
🐍🍒⛏🤖

@vstinner vstinner deleted the thread_run branch June 21, 2021 11:16
@miss-islington
Copy link
Contributor

Sorry, @vstinner, I could not cleanly backport this to 3.9 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 45a78f906d2d5fe5381d78466b11763fc56d57ba 3.9

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Jun 21, 2021
_thread.start_new_thread() no longer calls PyThread_exit_thread()
explicitly at the thread exit, the call was redundant.

On Linux with the glibc, pthread_cancel() loads dynamically the
libgcc_s.so.1 library. dlopen() can fail if there is no more
available file descriptor to open the file. In this case, the process
aborts with the error message:

"libgcc_s.so.1 must be installed for pthread_cancel to work"

pthread_cancel() unwinds back to the thread's wrapping function that
calls the thread entry point.

The unwind function is dynamically loaded from the libgcc_s library
since it is tightly coupled to the C compiler (GCC). The unwinder
depends on DWARF, the compiler generates DWARF, so the unwinder
belongs to the compiler.

Thanks Florian Weimer and Carlos O'Donell for their help on
investigating this issue.
(cherry picked from commit 45a78f9)

Co-authored-by: Victor Stinner <vstinner@python.org>
@bedevere-bot bedevere-bot removed the needs backport to 3.10 only security fixes label Jun 21, 2021
@bedevere-bot
Copy link

GH-26824 is a backport of this pull request to the 3.10 branch.

@vstinner
Copy link
Member Author

Thanks @erlend-aasland for the review! I merged my PR.

@bedevere-bot
Copy link

GH-26825 is a backport of this pull request to the 3.9 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Jun 21, 2021
vstinner added a commit that referenced this pull request Jun 21, 2021
…H-26825)

_thread.start_new_thread() no longer calls PyThread_exit_thread()
explicitly at the thread exit, the call was redundant.

On Linux with the glibc, pthread_cancel() loads dynamically the
libgcc_s.so.1 library. dlopen() can fail if there is no more
available file descriptor to open the file. In this case, the process
aborts with the error message:

"libgcc_s.so.1 must be installed for pthread_cancel to work"

pthread_cancel() unwinds back to the thread's wrapping function that
calls the thread entry point.

The unwind function is dynamically loaded from the libgcc_s library
since it is tightly coupled to the C compiler (GCC). The unwinder
depends on DWARF, the compiler generates DWARF, so the unwinder
belongs to the compiler.

Thanks Florian Weimer and Carlos O'Donell for their help on
investigating this issue.

(cherry picked from commit 45a78f9)
vstinner added a commit that referenced this pull request Jun 21, 2021
…H-26824)

_thread.start_new_thread() no longer calls PyThread_exit_thread()
explicitly at the thread exit, the call was redundant.

On Linux with the glibc, pthread_cancel() loads dynamically the
libgcc_s.so.1 library. dlopen() can fail if there is no more
available file descriptor to open the file. In this case, the process
aborts with the error message:

"libgcc_s.so.1 must be installed for pthread_cancel to work"

pthread_cancel() unwinds back to the thread's wrapping function that
calls the thread entry point.

The unwind function is dynamically loaded from the libgcc_s library
since it is tightly coupled to the C compiler (GCC). The unwinder
depends on DWARF, the compiler generates DWARF, so the unwinder
belongs to the compiler.

Thanks Florian Weimer and Carlos O'Donell for their help on
investigating this issue.
(cherry picked from commit 45a78f9)

Co-authored-by: Victor Stinner <vstinner@python.org>
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.

5 participants