reaperhulk
commented
4 years ago Do you see the same segfault with the binary wheel? What flags were used during compilation?
Closed patrickkidd closed 3 years ago
reaperhulk
commented
4 years ago Do you see the same segfault with the binary wheel? What flags were used during compilation?
patrickkidd
commented
4 years ago Do you see the same segfault with the binary wheel? What flags were used during compilation?
I see it with the current binary wheel:
turin:~ patrick$ pip install --only-binary :all bcrypt
Collecting bcrypt
Using cached bcrypt-3.1.7-cp34-abi3-macosx_10_6_intel.whl (53 kB)
Requirement already satisfied: six>=1.4.1 in ./dev/vendor/sysroot-dev/lib/python3.6/site-packages (from bcrypt) (1.14.0)
Requirement already satisfied: cffi>=1.1 in ./dev/vendor/sysroot-dev/lib/python3.6/site-packages (from bcrypt) (1.13.2)
Requirement already satisfied: pycparser in ./dev/vendor/sysroot-dev/lib/python3.6/site-packages (from cffi>=1.1->bcrypt) (2.19)
Installing collected packages: bcrypt
Successfully installed bcrypt-3.1.7
turin:~ patrick$ python -c "import bcrypt"
* ob
object : <refcnt 0 at 0x10c209c98>
type : tuple
refcount: 0
address : 0x10c209c98
* op->_ob_prev->_ob_next
object : <refcnt 0 at 0x10c209c97>Segmentation fault: 11
turin:~ patrick$Here is how I configured Python-3.6.4:
export CFLAGS="-I$(brew --prefix openssl)/include -I$(xcrun --show-sdk-path)/usr/include -Wno-nullability-completeness -Wno-strict-prototypes"
export LDFLAGS="-L$(brew --prefix openssl)/lib -I$(xcrun --show-sdk-path)/usr/lib"
cp ../../../src/Python-$PYTHON_VERSION-Setup.dist ./Modules
./configure --prefix=$SYSROOT -with-ensurepip=install --with-system-expat --with-pydebugOkay, I believe compiling with pydebug enabled makes it abi incompatible with the wheel (a fact that the wheel tags and pip don’t handle well for reasons I don’t know).
I don’t know why it’s crashing when you compile it yourself though...
patrickkidd
commented
4 years ago The diff from 3.1.3..3.1.4 - the change that breaks it - looks pretty minimal, though I don't know much about travis or Jenkins.
I attached to the process with Xcode. I wish I had some CPython object printers for lldb. But it is failing in the Py_TYPE line below (as indicated in the stack trace in the original post):
/* XXX(twouters) cast refcount to long until %zd is
universally available */
fprintf(stderr, "\n"
"type : %s\n"
"refcount: %ld\n"
"address : %p\n",
Py_TYPE(op)==NULL ? "NULL" : Py_TYPE(op)->tp_name,
(long)op->ob_refcnt,
op);... called from the second _PyObject_Dump() here:
if (op == &refchain ||
op->_ob_prev->_ob_next != op || op->_ob_next->_ob_prev != op) {
fprintf(stderr, "* ob\n");
_PyObject_Dump(op);
fprintf(stderr, "* op->_ob_prev->_ob_next\n");
_PyObject_Dump(op->_ob_prev->_ob_next);
fprintf(stderr, "* op->_ob_next->_ob_prev\n");
_PyObject_Dump(op->_ob_next->_ob_prev);
Py_FatalError("UNREF invalid object");
}Is this still replicable on 3.2.0 with 10.15.6? Does it happen with Python 3.6.12? The C diff from 3.1.3 to 3.1.4 is just some include ordering and include guards so it is extremely weird that this would be happening (and apparently only on your machine). You might also make sure you're on latest cffi.
alex
commented
3 years ago no response in several months, closing.
patrickkidd
commented
3 years ago Sorry, somehow I either missed the replies or failed to respond.
This does not occur with the following two setups:
I don't have access to macOS 10.15.* anymore, sorry.
I am getting the following segfault on python-3.6.4 built from source on macOS 10.5.3. The bug was introduced in bcrypt-3.1.4