io.IOBase destructor silence I/O error on close() by default

[ionelmc]

BPO	18748
Nosy	@pitrou, @vstinner, @tirkarthi
PRs	bpo-18748: io.IOBase destructor now logs close() errors in dev mode #12786 bpo-18748: test_io: silence destructor errors #12805 bpo-18748: _pyio.IOBase emits unraisable exception #13512 bpo-18748: Fix _pyio.IOBase destructor (closed case) #13952
Files	bug.py

^{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

• gh-62948: IOBase finalizer logs close() exceptions #105104

[ionelmc]

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]

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]

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]

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]

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]

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]

What is the version of your libc library? Try something like "dpkg -l
libc6".

2.15-0ubuntu10.4

I don't think it's that obscure ... uwsgi has this issue
https://www.google.com/search?q=libgcc_s.so.1+must+be+installed+for+pthread_cancel+to+work+uwsgi+site:lists.unbit.it-
they cause it probably different but the point is that it's not
obscure.

[ionelmc]

Correct link https://www.google.com/search?q=libgcc_s.so.1+must+be+installed+for+pthread_cancel+to+work+uwsgi+site:lists.unbit.it

[vstinner]

2013/8/17 Maries Ionel Cristian <report@bugs.python.org>:

I don't think it's that obscure ... uwsgi has this issue
https://www.google.com/search?q=libgcc_s.so.1+must+be+installed+for+pthread_cancel+to+work+uwsgi+site:lists.unbit.it-
they cause it probably different but the point is that it's not
obscure.

The error message is maybe the same, the reason is completly different:
http://lists.unbit.it/pipermail/uwsgi/2013-July/006213.html
"IT WAS A limit-as issue"

The root cause is an arbitrary limit on the size of the virtual memory.

Here the bug is that a thread B closes a file descriptor opened in a
thread B by the glibc.

[ionelmc]

Well anyway, is there any way to preload libgcc ? Because in python2.x it wasn't loaded at runtime.

[vstinner]

2013/8/18 Maries Ionel Cristian <report@bugs.python.org>:

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]

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?