[issue46959] ctypes.util.find_library can delete /dev/null
New submission from Barry Davis :
This bug exists again: https://bugs.python.org/issue1521375
In ctypes/util we defend against gcc removing /dev/null by using a temp file,
but similar code for ld still uses /dev/null, resulting in it removing
/dev/null if it has permission, i.e. if running as root.
Reproduction steps in the original bug still work I think.
I found this when running pyinstaller.
I slimmed the test case down to:
import ctypes.util
libname = ctypes.util.find_library("ApplicationServices")
Here's my patch (indentation is wrong to just show the actual change needed):
--- Python-3.10.2/Lib/ctypes/util.py2022-03-08 14:34:52.188808751 +
+++ Python-3.10.2/Lib/ctypes/util.py2022-03-08 14:40:23.604615242 +
@@ -305,9 +305,11 @@
if libpath:
for d in libpath.split(':'):
cmd.extend(['-L', d])
-cmd.extend(['-o', os.devnull, '-l%s' % name])
-result = None
+temp = tempfile.NamedTemporaryFile()
try:
+ cmd.extend(['-o', temp.name, '-l%s' % name])
+ result = None
+ try:
p = subprocess.Popen(cmd, stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
universal_newlines=True)
@@ -320,8 +322,15 @@
if not _is_elf(file):
continue
return os.fsdecode(file)
-except Exception:
+ except Exception:
pass # result will be None
+finally:
+try:
+temp.close()
+except FileNotFoundError:
+# Raised if the file was already removed, which is the
normal
+# behaviour if linking fails
+pass
return result
def find_library(name):
--
components: Library (Lib)
messages: 414756
nosy: barry.c.davis
priority: normal
severity: normal
status: open
title: ctypes.util.find_library can delete /dev/null
type: behavior
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue46959>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31171] multiprocessing.BoundedSemaphore of 32-bit python could not work while cross compiling on linux platform
Barry Davis added the comment:
I've just hit this issue using Python-2.7.9, gcc-8.1.0, glibc-2.23.
The patch I made to fix the issue based on comments in this issue:
--- Python-2.7.9/setup.py 2019-01-25 09:30:39.049501423 +
+++ Python-2.7.9/setup.py 2019-01-25 09:30:55.369609646 +
@@ -1670,7 +1670,7 @@
else: # Linux and other unices
macros = dict()
-libraries = ['rt']
+libraries = ['rt', 'pthread']
if host_platform == 'win32':
multiprocessing_srcs = [ '_multiprocessing/multiprocessing.c',
@@ -1690,6 +1690,7 @@
if sysconfig.get_config_var('WITH_THREAD'):
exts.append ( Extension('_multiprocessing', multiprocessing_srcs,
+libraries = libraries,
define_macros=macros.items(),
include_dirs=["Modules/_multiprocessing"]))
else:
--
nosy: +Barry Davis
___
Python tracker
<https://bugs.python.org/issue31171>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31171] multiprocessing.BoundedSemaphore of 32-bit python could not work while cross compiling on linux platform
Barry Davis added the comment:
The behaviour I saw (32-bit only) was a python process getting stuck.
I got this from strace:
...
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
futex(0xb5acc000, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily
unavailable)
...
And this from gdb:
(gdb) bt
#0 0xb76fbc5d in __kernel_vsyscall ()
#1 0xb74af2a4 in sem_wait () from /lib/libpthread.so.0
#2 0xb69a5429 in ?? () from /usr/lib/python2.7/lib-dynload/_multiprocessing.so
#3 0xb75a262e in call_function (oparg=, pp_stack=0xbfb7f038) at
Python/ceval.c:4033
#4 PyEval_EvalFrameEx (f=, throwflag=) at
Python/ceval.c:2679
#5 0xb75a2f7d in PyEval_EvalCodeEx (co=, globals=
{'Queue': , 'atexit': , 'Semaphore': , 'Empty': , 'Full': , 'SimpleQueue': , 'assert_spawning': ,
'__all__': ['Queue', 'SimpleQueue', 'JoinableQueue'], '_multiprocessing':
, '_sentinel': ,
'__package__': 'multiprocessing', 'collections': ,
'__doc__': None, 'Condition': , 'JoinableQueue':
, '__builtins__': {'bytearray': , 'IndexError': , 'all': , 'help': <_Helper at remote 0xb71f824c>, 'vars': , 'SyntaxError': , 'unicode': , 'UnicodeDecodeError': ,
'memoryview': , 'isinstance...(truncated), locals=0x0, args=0xb535f5cc,
argcount=2, kws=0xb535f5d4, kwcount=0, defs=0xb69b6058, defcount=2,
closure=0x0) at Python/ceval.c:3265
#6 0xb75a0f3d in fast_function (nk=0, na=, n=2,
pp_stack=0xbfb7f178, func=) at
Python/ceval.c:4129
#7 call_function (oparg=, pp_stack=0xbfb7f178) at
Python/ceval.c:4054
#8 PyEval_EvalFrameEx (f=, throwflag=) at
Python/ceval.c:2679
...
(gdb) py-bt
#4 Frame 0xb536602c, for file /usr/lib/python2.7/multiprocessing/queues.py,
line 101, in put (self=, _recv=, _thread=None, _sem=,
acquire=, _semlock=<_multiprocessing.SemLock at remote 0xb53427c0>) at
remote 0xb53425cc>, _buffer=,
_closed=False, _send=, _jointhread=None, _reader=None, _opid=3752,
_rlock=, acquire=,
_semlock=<_multiprocessing.SemLock at remote 0xb53424
20>) at remote 0xb534240c>, _...(truncated)
...
--
___
Python tracker
<https://bugs.python.org/issue31171>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Changes by Barry Davis : -- versions: +Python 3.6 ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Barry Davis added the comment: I think this is the same issue I'm getting. I'm hitting it when compiling python 3.6.2 compiled with gcc-4.8.4. This wasn't occasional, it was every time I tried. As a feeble workaround I was compiling in parallel, then in serial when it fails, although I'm now hitting the same issue when building uwsgi-2.0.15. I'm building on a 56 core system so that might make me more likely to hit the issue. -- nosy: +Barry Davis ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Barry Davis added the comment: Looks like I was mistaken. My cross compiler was trying to load libgcc_s.so.1 from the standard location and not liking the one it found. Fixed for now by setting LD_LIBRARY_PATH to point at the dir containing the right libgcc_s.so.1 -- versions: -Python 3.6 ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18748] libgcc_s.so.1 must be installed for pthread_cancel to work
Barry Davis added the comment: I meant my cross compiled python, not my cross compiler. -- ___ Python tracker <http://bugs.python.org/issue18748> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
