Closed patrickkidd closed 3 years ago
Do you see the same segfault with the binary wheel? What flags were used during compilation?
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-pydebug
Okay, 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...
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.
no response in several months, closing.
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