Home Original page

Issue 11915: test_ctypes hangs in sandbox

Issue11915

Created on 2011-04-24 19:38 by Arfrever, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
sandbox_exec_bug.c vstinner, 2011-04-25 01:08
static.c vstinner, 2011-04-25 01:09
Messages (14)
msg134341 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-24 19:38 
After 19d9f0a177de and 020ebe0be33e, test_ctypes hangs when test suite is run in sandbox. This problem occurs only in Python 3.3.

$ sandbox python3.3 -B -m test.regrtest --timeout=10 -v test_ctypes
== CPython 3.3a0 (default:020ebe0be33e+, Apr 24 2011, 17:52:58) [GCC 4.5.2]
==   Linux-${version}
==   /tmp/test_python_23902
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=1, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0)
[1/1] test_ctypes
Timeout (0:00:10)!
Thread 0x00007fc205f54700:
  File "/usr/lib64/python3.3/subprocess.py", line 466 in _eintr_retry_call
  File "/usr/lib64/python3.3/subprocess.py", line 1412 in _execute_child
  File "/usr/lib64/python3.3/subprocess.py", line 766 in __init__
  File "/usr/lib64/python3.3/ctypes/util.py", line 198 in _findSoname_ldconfig
  File "/usr/lib64/python3.3/ctypes/util.py", line 206 in find_library
  File "/usr/lib64/python3.3/ctypes/test/test_find.py", line 15 in <module>
  File "/usr/lib64/python3.3/ctypes/test/__init__.py", line 64 in get_tests
  File "/usr/lib64/python3.3/test/test_ctypes.py", line 11 in test_main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1094 in runtest_inner
  File "/usr/lib64/python3.3/test/regrtest.py", line 887 in runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 587 in _runtest
  File "/usr/lib64/python3.3/test/regrtest.py", line 711 in main
  File "/usr/lib64/python3.3/test/regrtest.py", line 1672 in <module>
  File "/usr/lib64/python3.3/runpy.py", line 73 in _run_code
  File "/usr/lib64/python3.3/runpy.py", line 160 in _run_module_as_main
msg134342 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-24 19:46 
Reverting of 19d9f0a177de is sufficient to avoid this problem.
msg134343 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-04-24 19:50 
What do you call "sandbox" ?
Also, would be nice if you investigated a bit more about the causes. From the traceback, it looks like the child process is stuck inside exec().
msg134344 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-24 19:53 
wget http://gentoo.osuosl.org/distfiles/sandbox-2.5.tar.xz
tar -xJf sandbox-2.5.tar.xz
cd sandbox-2.5
./configure
make
make install
msg134345 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-04-24 21:18 
> http://gentoo.osuosl.org/distfiles/sandbox-2.5.tar.xz

What is this file? Where does it come from?
msg134346 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-24 21:31 
It's a source tarball of sandbox implementation used by default in Gentoo. Sandbox is enabled during building/testing/installation of all packages in Gentoo. Sandbox e.g. disallows write access to directories outside of build directory (even when run by root).

Alternatively you can download sources from git repository:
http://git.overlays.gentoo.org/gitweb/?p=proj/sandbox.git;a=summary
msg134347 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2011-04-24 21:42 
New changeset 2c0da1c4f063 by Victor Stinner in branch 'default':
Issue #11915: threading.RLock()._release_save() raises a RuntimeError if the
http://hg.python.org/cpython/rev/2c0da1c4f063
msg134353 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-24 22:15 
Moving discussion to issue #11258.
msg134356 - (view) Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * (Python triager) Date: 2011-04-24 22:21 
(Revision 2c0da1c4f063 mistakenly refers to this issue. This revision is actually for issue #11005.)
msg134361 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-04-25 01:08 
This issue comes from sandbox, not from ctypes.

Using sandbox, execv() C function doesn't close files with FD_CLOEXEC flag if the child program is a static program.

test_ctypes hangs on find_library() in subprocess.Popen._execute_child():
 - create a pipe for the child exception (if any)
 - fork
 - the parent reads this pipe
 - the child calls exec()
 - exec() closes the pipe and the parent continues its work
 - etc.

find_library() runs "ldconfig -p" in a subprocess, and so everything hangs on "the parent reads this pipe" because "exec() closes the pipe and the parent continues its work" doesn't occur.
msg134362 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-04-25 01:09 
If you would like to reproduce sandbox bug:

gcc sandbox_exec_bug.c -o sandbox_exec_bug
gcc -static static.c -o static
sandbox ./sandbox_exec_bug

The bug doesn't occur if static.c is not compiled with -static.

Note: I don't know if "sandbox ./sandbox_exec_bug" is the right command to run ./sandbox_exec_bug in the sandbox, I used directly LD_PRELOAD.
msg134363 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-04-25 01:10 
I close this issue because it is not a Python. I will try to open an issue in Gentoo bugtracker, but now I am too tired to do that :-)
msg134364 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-04-25 01:18 
If the child program is static, sandbox protects it using a tracing mechanism (based on ptrace with PTRACE_SYSCALL). Output is debug mode:

trace_main tracing: ./static
TRACE (pid=10377):trace_main: parent waiting for child (pid=10378) to signal
TRACE (pid=10378):trace_main: child setting up ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGSTOP(19)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGCONT(18)
TRACE (pid=10377):trace_loop: >IDK:62TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
TRACE (pid=10377):trace_loop: >IDK:11TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
TRACE (pid=10377):trace_loop: >IDK:3TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
(...pre-exec...) = ...
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 36896768
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 36901248
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 0
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 37036416
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 37040128
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = 1264893952
TRACE (pid=10377):trace_child_signal: got sig SIGCHLD(17): code:CLD_TRAPPED(4) status:SIGTRAP(5)
 = -1 (errno: 38: Function not implemented)
msg134429 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2011-04-25 23:57 
I reported the bug on Gentoo bug tracker:
http://bugs.gentoo.org/show_bug.cgi?id=364877
History
Date User Action Args
2022-04-11 14:57:16adminsetgithub: 56124
2011-04-25 23:57:20vstinnersetmessages: + msg134429
2011-04-25 01:18:40vstinnersetmessages: + msg134364
2011-04-25 01:10:49vstinnersetstatus: open -> closed
resolution: not a bug
messages: + msg134363
2011-04-25 01:09:59vstinnersetfiles: + static.c

messages: + msg134362

2011-04-25 01:08:14vstinnersetfiles: + sandbox_exec_bug.c

messages: + msg134361

2011-04-24 22:21:30Arfreversetmessages: + msg134356
2011-04-24 22:19:16Arfreversetnosy: + vapier, jonash
2011-04-24 22:16:30pitrousetstatus: closed -> open
resolution: duplicate -> (no value)
2011-04-24 22:15:35Arfreversetstatus: open -> closed
resolution: duplicate
messages: + msg134353
2011-04-24 21:42:26python-devsetnosy: + python-dev
messages: + msg134347
2011-04-24 21:31:03Arfreversetmessages: + msg134346
2011-04-24 21:18:42vstinnersetnosy: + vstinner
messages: + msg134345
2011-04-24 19:53:17Arfreversetmessages: + msg134344
2011-04-24 19:50:48pitrousetmessages: + msg134343
2011-04-24 19:46:55Arfreversetmessages: + msg134342
2011-04-24 19:38:15Arfrevercreate