Issue 11915: test_ctypes hangs in sandbox (original) (raw)

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

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 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 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:16

admin

set

github: 56124

2011-04-25 23:57:20

vstinner

set

messages: +

2011-04-25 01🔞40

vstinner

set

messages: +

2011-04-25 01:10:49

vstinner

set

status: open -> closed
resolution: not a bug
messages: +

2011-04-25 01:09:59

vstinner

set

files: + static.c

messages: +

2011-04-25 01:08:14

vstinner

set

files: + sandbox_exec_bug.c

messages: +

2011-04-24 22:21:30

Arfrever

set

messages: +

2011-04-24 22:19:16

Arfrever

set

nosy: + vapier, jonash

2011-04-24 22:16:30

pitrou

set

status: closed -> open
resolution: duplicate -> (no value)

2011-04-24 22:15:35

Arfrever

set

status: open -> closed
resolution: duplicate
messages: +

2011-04-24 21:42:26

python-dev

set

nosy: + python-dev
messages: +

2011-04-24 21:31:03

Arfrever

set

messages: +

2011-04-24 21🔞42

vstinner

set

nosy: + vstinner
messages: +

2011-04-24 19:53:17

Arfrever

set

messages: +

2011-04-24 19:50:48

pitrou

set

messages: +

2011-04-24 19:46:55

Arfrever

set

messages: +

2011-04-24 19:38:15

Arfrever

create