GeezerVison is showing github.com — io.IOBase destructor silence I/O error on close() by default · Issue #62948 · python/cpython
io.IOBase destructor silence I/O error on close() by default #62948Description
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 = <Date 2019-06-12.23:14:43.171>
created_at = <Date 2013-08-15.13:10:42.326>
labels = ['extension-modules', 'build', '3.8', '3.9', 'type-crash']
title = 'io.IOBase destructor silence I/O error on close() by default'
updated_at = <Date 2021-06-28.23:33:12.533>
user = 'https://bugs.python.org/ionelmc' bugs.python.org fields:
activity = <Date 2021-06-28.23:33:12.533>
actor = 'vstinner'
assignee = 'none'
closed = True
closed_date = <Date 2019-06-12.23:14:43.171>
closer = 'vstinner'
components = ['Build', 'Extension Modules']
creation = <Date 2013-08-15.13:10:42.326>
creator = 'ionelmc'
dependencies = []
files = ['31301']
hgrepos = []
issue_num = 18748
keywords = ['patch']
message_count = 39.0
messages = ['195253', '195319', '195321', '195324', '195325', '195342', '195505', '195507', '195523', '195525', '195527', '195528', '195565', '294551', '294873', '294874', '339502', '339979', '340055', '340056', '340058', '340059', '340062', '340104', '341106', '342483', '342484', '342493', '343270', '343699', '345157', '345160', '345422', '345428', '347240', '347268', '347284', '348515', '396673']
nosy_count = 9.0
nosy_names = ['pitrou', 'vstinner', 'ionelmc', 'neologix', 'nikicat', 'zwol', 'Barry Davis', 'xtreak', 'Yhojann Aguilera']
pr_nums = ['12786', '12805', '13512', '13952']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'crash'
url = 'https://bugs.python.org/issue18748'
versions = ['Python 3.6', 'Python 3.8', 'Python 3.9'] Linked PRs
Activityionelmc commented on Aug 15, 2013 MannequinAuthor More actions Running the file couple of times will make the interpreter fail with: libgcc_s.so.1 must be installed for pthread_cancel to work
From what I've seen it is triggered from PyThread_delete_key (tries to load libgcc_s.so at that time).
How does it happen?
The main thread will close fd 4 (because fh object is getting dereferenced to 0) exactly at the same time libpthread will try to open and read libgcc_s.so with the same descriptor (4)
It's fairly obvious that the file handling in bug.py is a bug, but the interpreter should not crash like that !
This doesn't happen on python2.7. Also, python2.7 appears to be linked with libgcc_s.so.1 directly while the 3.x does not (I've tried 3.2 from ubuntu repos, and built 3.3 and 3.4 myself on ubuntu 12.04.2) - at least that's what ldd indicates. neologix commented on Aug 16, 2013 Unfortunately, there's not much we can do about it: if dlsym() fails - which is the case here either because read() fails with EBADF, or because the file descriptor now points to another stream (i.e. not libgcc), the libc aborts (here upon pthread_exit(), not PyThread_delete_key()):
"""
libgcc_s.so.1 must be installed for pthread_cancel to work
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb7b0eb70 (LWP 17152)]
0xb7fe1424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fe1424 in __kernel_vsyscall ()
#1 0xb7e4e941 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7e51d72 in *__GI_abort () at abort.c:92
#3 0xb7e8ae15 in __libc_message (do_abort=1, fmt=0xb7f606f5 "%s") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189
#4 0xb7e8af44 in *__GI___libc_fatal (message=0xb7fc75ec "libgcc_s.so.1 must be installed for pthread_cancel to work\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:200
#5 0xb7fc4ffa in pthread_cancel_init () at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:65
#6 0xb7fc509d in _Unwind_ForcedUnwind (exc=0xb7b0edc0, stop=0xb7fc2bf0 <unwind_stop>, stop_argument=0xb7b0e454) at ../nptl/sysdeps/pthread/unwind-forcedunwind.c:126
#7 0xb7fc2b98 in *__GI___pthread_unwind (buf=<optimized out>) at unwind.c:130
#8 0xb7fbcce0 in __do_cancel () at pthreadP.h:265
#9 __pthread_exit (value=0x0) at pthread_exit.c:30
#10 0x08132ced in PyThread_exit_thread () at Python/thread_pthread.h:266
#11 0x08137c37 in t_bootstrap (boot_raw=0x8318aa8) at ./Modules/_threadmodule.c:1023
#12 0xb7fbbc39 in start_thread (arg=0xb7b0eb70) at pthread_create.c:304
#13 0xb7ef978e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
"""
So if you're unlucky and end up closing the FD referring to libgcc used by dlopen/dlsym, you're pretty much screwed, and there's no way around this.
Note that you specific problem (upon PyThread_delete_key()) doesn't occur for python 2.7 because it uses and ad-hoc TLS implementation, whereas Python 3 uses the platform native TLS.
But as noted above, you can very well get an abort on pthread_exit(), and in likely many other places (pretty much everywhere libgcc can be dlopen'ed).
Unfortunately, we can't do much against this, so I'm tempted to close this as "wont fix". pitrou commented on Aug 16, 2013 Perhaps the only thing we could do would be try to "preload" libgcc by calling one of those APIs at startup? But I'm not sure it's a good idea to add such a platform-specific hack (for what is arguably an obscure and rare issue). vstinner commented on Aug 16, 2013 Maries Ionel Cristian> ubuntu 12.04.2
What is the version of your libc library? Try something like "dpkg -l libc6".
--
Could this issue be related to this glibc issue?
http://sourceware.org/bugzilla/show_bug.cgi?id=2644
I ran your script on Python 3.4 in a shell loop: I'm unable to reproduce the issue. I'm running Fedora 18 with the glibc 2.16. vstinner commented on Aug 16, 2013 Oh ok, I'm able to reproduce the issue with the system Python 3.3:
$ while true; do echo "loop"; python3.3 bug.py || break; done
loop
...
loop
libgcc_s.so.1 must be installed for pthread_cancel to work
Abandon (core dumped) neologix commented on Aug 16, 2013
Perhaps the only thing we could do would be try to "preload" libgcc by
calling one of those APIs at startup?
Yeah, I was thinking about doing this in PyThread_init_thread() but...
But I'm not sure it's a good idea to
add such a platform-specific hack (for what is arguably an obscure and rare
issue).
then thought the exact same thing.
Also, this exact problem can possibly show up anywhere dlopen() is
used (a grep through glibc code shows at least an occurrence in
nsswitch-related code). ionelmc commented on Aug 17, 2013 MannequinAuthor More actions ionelmc commented on Aug 17, 2013 MannequinAuthor More actions vstinner commented on Aug 17, 2013 ionelmc commented on Aug 17, 2013 MannequinAuthor More actions Well anyway, is there any way to preload libgcc ? Because in python2.x it wasn't loaded at runtime. vstinner commented on Aug 17, 2013 2013/8/18 Maries Ionel Cristian <[email protected]>:
Well anyway, is there any way to preload libgcc ? Because in python2.x it wasn't loaded at runtime.
On Linux, you can try to set the LD_PRELOAD environment variable as a
workaround.
LD_PRELOAD=libgcc_s.so.1 python bug.py You may need to specify the full path. ionelmc commented on Aug 17, 2013 MannequinAuthor More actions Alright ... would it be a very big hack to preload libgcc in the thread module (at import time) ? There is platform specific code there anyway, it wouldn't be such a big deal would it? vstinner commented on Jul 4, 2019
Same problem using Python 3.6.8 on Ubuntu 18.04 LTS.
To be clear: this issue is NOT a bug in Python, but a bug in your application. You must fix your application. You can try to run it on Python 3.8 with python3.8 -X dev to get a log on the error. Good luck to debug it ;-)
The change that I made is only to add a log to help developers to find their own bugs ;-) zwol commented on Jul 4, 2019
To be clear: this issue is NOT a bug in Python
I don't think that's entirely true. I think CPython needs to be linked against libgcc_s.so, so that this class of application bugs will no longer manifest as interpreter crashes. I filed bpo-37395 for that. YhojannAguilera commented on Jul 26, 2019 I hope that when an error occurs, python tells me what the problem is. The abort core error is a problem at a lower level than python because python is not able to recognize or handle the error.
The main problem is that I exceeded the maximum number of process threads supported by the kernel.
What I hope is that python throws an exception when it exceeds this limit or when it cannot access the pointer in memory of the process thread.
The problem is not if the script is right or wrong, but that Python is not able to recognize and handle the problem. A generic message saying that an error occurred without indicating where and how it occurred is a python bug. vstinner commented on Jun 28, 2021
Running the file couple of times will make the interpreter fail with: libgcc_s.so.1 must be installed for pthread_cancel to work
See also bpo-44434: "_thread module: Remove redundant PyThread_exit_thread() call to avoid glibc fatal error: libgcc_s.so.1 must be installed for pthread_cancel to work".
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|