Closed nedbat closed 4 years ago
Original comment by Buck Evan (Bitbucket: bukzor, GitHub: bukzor)
I 100% understand. In case you ever do want to come back to it, I have an automated reproduction here:
The main mystery is: why is python reloading the tracer.so so late? I would have expected it to be loaded into memory much earlier, making filesystem operations irrelevant. Is it reloading the .so on each call_trace()?
Buck: you've made an impressive scenario here. I'll be honest with you: I don't think I am going to be able to dig into it.
Original comment by Buck Evan (Bitbucket: bukzor, GitHub: bukzor)
This seems to be a minimal reproduction:
mkdir tmp2
cd tmp2/
virtualenv tmpvenv
./tmpvenv/bin/pip install --upgrade pip wheel coverage
./tmpvenv/bin/pip wheel coverage
./tmpvenv/bin/python -m coverage.__main__ run -m pip install --no-index --ignore-installed --find-links wheelhouse/ coverage
Output:
Ignoring indexes: https://pypi.python.org/simple/
Downloading/unpacking coverage
Installing collected packages: coverage
Bus error (core dumped)
Notable features:
Originally reported by Buck Evan (Bitbucket: bukzor, GitHub: bukzor)
I have a system which attempts to wrap pip. I need to test installing things. I chose to install the coverage package as a test scenario. The test is being run under coverage. I get a "bus error".
On closer inspection, the bus error occurs while cpython is calling call_trace() for a python-level call to copyfile() of the tracer.so, and afterwards the .so file is an empty file.
I can work around this by not using coverage as a test scenario, but there might be bugs revealed by this scenario that you'd be interested in fixing.
Here's a trace of the core dump, first at a python level, then at a C level: