Okay, I found the problem and the fix. We are missing the python2_qstring.diff patch that Debian uses to fix this crash in py27-pyqt5. I've opened a ticket with a Portfile.diff for py-pyqt5 and the python2_qstring.diff patch file to eliminate these crashes in the default python27 variant of pymol under the qt5 interface.
https://trac.macports.org/ticket/59358 Jack On Wed, Oct 16, 2019 at 6:36 PM Jack Howarth <howarth.at.macpo...@gmail.com> wrote: > Does the default python27 variant of pymol run without a segfault for > anyone under Mojave? I am finding that a clean installation of MacPorts > against Xcode 10.2.1 produces a pymol that shows the same crash. So we seem > to have suffered a regression since the last pymol commit. > Jack > ps Do the binary servers retain the older versions of the python27 > packages? I am tempted to walk back through them and see if I can find a > version that still works. > > On Tue, Oct 15, 2019 at 8:50 PM Jack Howarth < > howarth.at.macpo...@gmail.com> wrote: > >> Another data point. Starting with a clean installation of Mojave 10.14.6 >> supplement, Xcode 11.1 and MacPorts 2.6.1, a clean install of pymol and its >> dependences show the same exact crash under the Qt interface. Only a couple >> qt packages got rebuilt as well as py27-pyqt5 and pymol. So this looks like >> it is a code generation problem in one of them. I'll regress back to Xcode >> 10 and confirm which one being rebuilt against the older compiler >> eliminates the crash. Also, does anyone know for certain whether the Xcode >> 11 compilers emit the same stack checking code under 10.14 as it does under >> 10.15? >> Jack >> >> On Mon, Oct 14, 2019 at 5:52 PM Jack Howarth < >> howarth.at.macpo...@gmail.com> wrote: >> >>> I've also been able to test the python27 variant of pymol against both >>> py27-pyqt5 and python27 packages built with -fno-stack-check passed to >>> clang and clang++ in Xcode 11.2 beta 2 and the crash in the Qt interface of >>> pymol remains. The crashing thread shows the following in the crash log... >>> >>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread >>> 0 org.qt-project.QtCore 0x00000001081ac641 0x107ffd000 + >>> 1766977 >>> 1 org.qt-project.QtCore 0x000000010808c6c3 >>> QString::fromUtf16(unsigned short const*, int) + 53 >>> 2 QtCore.so 0x000000010990ff1d >>> qpycore_PyObject_AsQString(_object*) + 24 >>> 3 QtCore.so 0x000000010990ff83 qpycore_qt_conf() >>> + 91 >>> 4 QtCore.so 0x0000000109802965 >>> qpycore_post_init(_object*) + 665 >>> 5 org.python.python 0x0000000104227b36 >>> _PyImport_LoadDynamicModule + 150 >>> 6 org.python.python 0x000000010422654d import_submodule + >>> 285 >>> 7 org.python.python 0x0000000104225fde load_next + 270 >>> 8 org.python.python 0x0000000104224e5b >>> PyImport_ImportModuleLevel + 843 >>> 9 org.python.python 0x00000001041fe8a9 builtin___import__ >>> + 137 >>> 10 org.python.python 0x0000000104157f6e >>> PyObject_CallFunction + 318 >>> 11 org.python.python 0x00000001042249c1 PyImport_Import + >>> 353 >>> 12 org.python.python 0x00000001042227dc >>> PyImport_ImportModule + 28 >>> 13 sip.so 0x000000010870512f >>> sip_api_export_module + 82 >>> 14 QtGui.so 0x0000000107a3f78e initQtGui + 225 >>> 15 org.python.python 0x0000000104227b36 >>> _PyImport_LoadDynamicModule + 150 >>> 16 org.python.python 0x000000010422654d import_submodule + >>> 285 >>> 17 org.python.python 0x000000010422633f ensure_fromlist + >>> 575 >>> 18 org.python.python 0x0000000104224f0f >>> PyImport_ImportModuleLevel + 1023 >>> 19 org.python.python 0x00000001041fe8a9 builtin___import__ >>> + 137 >>> 20 org.python.python 0x0000000104157dc1 PyObject_Call + 97 >>> 21 org.python.python 0x0000000104207f26 PyEval_EvalFrameEx >>> + 16198 >>> 22 org.python.python 0x0000000104203d44 PyEval_EvalCodeEx >>> + 2004 >>> 23 org.python.python 0x0000000104203562 PyEval_EvalCode + >>> 34 >>> 24 org.python.python 0x0000000104223756 >>> PyImport_ExecCodeModuleEx + 230 >>> 25 org.python.python 0x0000000104226a78 load_source_module >>> + 968 >>> 26 org.python.python 0x0000000104226df1 load_package + 321 >>> 27 org.python.python 0x000000010422654d import_submodule + >>> 285 >>> 28 org.python.python 0x0000000104225fde load_next + 270 >>> 29 org.python.python 0x0000000104224e5b >>> PyImport_ImportModuleLevel + 843 >>> 30 org.python.python 0x00000001041fe8a9 builtin___import__ >>> + 137 >>> 31 org.python.python 0x0000000104157dc1 PyObject_Call + 97 >>> 32 org.python.python 0x0000000104207f26 PyEval_EvalFrameEx >>> + 16198 >>> 33 org.python.python 0x0000000104203d44 PyEval_EvalCodeEx >>> + 2004 >>> 34 org.python.python 0x0000000104203562 PyEval_EvalCode + >>> 34 >>> 35 org.python.python 0x0000000104223756 >>> PyImport_ExecCodeModuleEx + 230 >>> 36 org.python.python 0x0000000104226a78 load_source_module >>> + 968 >>> 37 org.python.python 0x000000010422654d import_submodule + >>> 285 >>> 38 org.python.python 0x000000010422633f ensure_fromlist + >>> 575 >>> 39 org.python.python 0x0000000104224f0f >>> PyImport_ImportModuleLevel + 1023 >>> 40 org.python.python 0x00000001041fe8a9 builtin___import__ >>> + 137 >>> 41 org.python.python 0x0000000104157dc1 PyObject_Call + 97 >>> 42 org.python.python 0x0000000104207f26 PyEval_EvalFrameEx >>> + 16198 >>> 43 org.python.python 0x0000000104203d44 PyEval_EvalCodeEx >>> + 2004 >>> 44 org.python.python 0x000000010420e96a fast_function + 106 >>> 45 org.python.python 0x0000000104209298 PyEval_EvalFrameEx >>> + 21176 >>> 46 org.python.python 0x0000000104203d44 PyEval_EvalCodeEx >>> + 2004 >>> 47 org.python.python 0x0000000104203562 PyEval_EvalCode + >>> 34 >>> 48 org.python.python 0x0000000104232131 PyRun_FileExFlags >>> + 161 >>> 49 org.python.python 0x0000000104231c2f >>> PyRun_SimpleFileExFlags + 751 >>> 50 org.python.python 0x0000000104249acf Py_Main + 3279 >>> 51 libdyld.dylib 0x00007fff6539d405 start + 1 >>> >>> So I guess rebuilding QtCore.so with -fno-stack-check is the next step. >>> Jack >>> >>> On Sun, Oct 13, 2019 at 2:10 PM Jack Howarth < >>> howarth.at.macpo...@gmail.com> wrote: >>> >>>> A few more data points. Testing builds of the pymol with the +python34, >>>> +python35, +python36 and +python37 on Catalina built with Xcode 11.2 beta >>>> 2 shows that none of them have issues running under the Qt interface. So >>>> this crash seems entirely specific to the +python27 variant of pymol. >>>> Jack >>>> >>>> On Sun, Oct 13, 2019 at 12:07 PM Chris Jones <jon...@hep.phy.cam.ac.uk> >>>> wrote: >>>> >>>>> >>>>> >>>>> On 13 Oct 2019, at 4:57 pm, Jack Howarth < >>>>> howarth.at.macpo...@gmail.com> wrote: >>>>> >>>>> >>>>> Another data point. Rebuilding python27 with this addition to the >>>>> Portfile... >>>>> >>>>> if { ([vercmp ${os.major} 19] >= 0) && ([vercmp $xcodeversion 11.3] < >>>>> 0) } { >>>>> if {[string match clang ${configure.compiler}]} { >>>>> configure.cc-append -fno-stack-check >>>>> } >>>>> } >>>>> >>>>> successfully passes -fno-stack-check to the build but the resulting >>>>> python2.7 doesn't suppress the pymol crashes with the QT interface. Maybe >>>>> the problem code is in py27-pyqt5? >>>>> >>>>> >>>>> Maybe. Or perhaps this is something different to the stack check >>>>> issue. .... >>>>> >>>>> Jack >>>>> >>>>> On Sun, Oct 13, 2019 at 11:38 AM Jack Howarth < >>>>> howarth.at.macpo...@gmail.com> wrote: >>>>> >>>>>> It would seem that this failure under Xcode 11.2 beta 2 is due to the >>>>>> current patch dropping -fno-stack-check for Xcode 11.2 in anticipation >>>>>> of a >>>>>> fix. >>>>>> >>>>>> # Workaround for test failure :- >>>>>> # > ./sblat2 < ./sblat2.dat >>>>>> # Program received signal SIGSEGV: Segmentation fault - invalid >>>>>> memory reference. >>>>>> # Current information is that this should be fixed in Xcode 11.2 >>>>>> if { ([vercmp ${os.major} 19] >= 0) && ([vercmp $xcodeversion 11.2] < >>>>>> 0) } { >>>>>> if {[string match clang ${configure.compiler}]} { >>>>>> configure.cc-append -fno-stack-check >>>>>> } >>>>>> } >>>>>> >>>>>> So this would seem to rule out OpenBLAS as the source of the pymol >>>>>> crashes under python2.7 with the QT interface as, under Xcode 11.1, >>>>>> OpenBLAS already built with -fno-stack-check. Perhaps the problem is in >>>>>> python2.7 when -fstack-check is used? >>>>>> Jack >>>>>> >>>>>> On Sun, Oct 13, 2019 at 11:08 AM Chris Jones < >>>>>> jon...@hep.phy.cam.ac.uk> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On 13 Oct 2019, at 4:02 pm, Jack Howarth < >>>>>>> howarth.at.macpo...@gmail.com> wrote: >>>>>>> >>>>>>> >>>>>>> Well this is interesting. After installing Xcode 11 Beta 2, Command >>>>>>> Line tools and setting the Xcode-select path to the Xcode-beta.app, I >>>>>>> find >>>>>>> that 'sudo port build OpenBLAS' now fails with... >>>>>>> >>>>>>> :info:build OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < >>>>>>> ./sblat2.dat >>>>>>> >>>>>>> :info:build Program received signal SIGSEGV: Segmentation fault - >>>>>>> invalid memory reference. >>>>>>> >>>>>>> :info:build Backtrace for this error: >>>>>>> >>>>>>> :info:build #0 0x1029863e4 >>>>>>> >>>>>>> :info:build #1 0x102985b06 >>>>>>> >>>>>>> :info:build #2 0x7fff688fab1c >>>>>>> >>>>>>> :info:build /bin/sh: line 1: 22671 Segmentation fault: 11 >>>>>>> OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < ./sblat2.dat >>>>>>> >>>>>>> :info:build make[1]: *** [level2] Error 139 >>>>>>> >>>>>>> :info:build make[1]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> :info:build make[1]: Leaving directory >>>>>>> `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/work/xianyi-OpenBLAS-5f36f18/test' >>>>>>> >>>>>>> >>>>>>> That just means the stack check issue is in fact not addressed in >>>>>>> 11.2, or there is in fact a real issue with the openblas source. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Oct 13, 2019 at 10:49 AM Jack Howarth < >>>>>>> howarth.at.macpo...@gmail.com> wrote: >>>>>>> >>>>>>>> Okay, I have Xcode 11.2 beta 2 and the associated Command Line >>>>>>>> Tools installed. Is there some permutation of options to pass to 'port' >>>>>>>> that will rebuild and reinstall a currently installed MacPorts package >>>>>>>> without uninstalling it first? >>>>>>>> Jack >>>>>>>> >>>>>>>> On Sun, Oct 13, 2019 at 10:13 AM Chris Jones < >>>>>>>> jon...@hep.phy.cam.ac.uk> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> > On 13 Oct 2019, at 3:11 pm, Joshua Root <j...@macports.org> >>>>>>>>> wrote: >>>>>>>>> > >>>>>>>>> > On 2019-10-14 00:59 , Jack Howarth wrote: >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >>> On Sun, Oct 13, 2019 at 9:49 AM Chris Jones < >>>>>>>>> jon...@hep.phy.cam.ac.uk >>>>>>>>> >>> <mailto:jon...@hep.phy.cam.ac.uk>> wrote: >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> >>> On 13 Oct 2019, at 2:46 pm, Joshua Root <j...@macports.org >>>>>>>>> >>> <mailto:j...@macports.org>> wrote: >>>>>>>>> >>> >>>>>>>>> >>> On 2019-10-14 00:35 , Chris Jones wrote: >>>>>>>>> >>>> >>>>>>>>> >>>> After that, my next guess would perhaps another issue >>>>>>>>> related to the >>>>>>>>> >>>> stack-check issue with Xcode 11. See e.g. the fix I added >>>>>>>>> for >>>>>>>>> >>>> OpenBLAS >>>>>>>>> >>>> >>>>>>>>> >>>> >>>>>>>>> https://github.com/macports/macports-ports/commit/6e78e5c9495b4dc4e7e050fae2b41dd5b9accfdd#diff-a755de84ca7f97ab071328807d829e0b >>>>>>>>> >>> >>>>>>>>> >>> I'd be wary of removing a hardening measure and leaving it >>>>>>>>> at that. It >>>>>>>>> >>> could be revealing a genuine stack-smashing bug. >>>>>>>>> >> >>>>>>>>> >> Agreed. Accordingly to Jeremy though its a Xcode bug >>>>>>>>> expected to be >>>>>>>>> >> fixed in 11.2. Thats why I subsequently added a version >>>>>>>>> check, see e.g. >>>>>>>>> > >>>>>>>>> > Ah, good to know. Do you have a link to Jeremy's statement out >>>>>>>>> of curiosity? >>>>>>>>> >>>>>>>>> No I don’t, I only know this second hand from a comment by Ken... >>>>>>>>> >>>>>>>>> > >>>>>>>>> >> >>>>>>>>> https://github.com/macports/macports-ports/blob/master/math/OpenBLAS/Portfile >>>>>>>>> >> >>>>>>>>> >> Line 109. >>>>>>>>> >> >>>>>>>>> >>> >>>>>>>>> >>> - Josh >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> Josh, >>>>>>>>> >> Does anyone know if this is already fixed in the posted >>>>>>>>> Xcode 11.2 >>>>>>>>> >> beta 2? If so, would rebuilding the OpenBLAS package with it be >>>>>>>>> >> sufficient or aren't we sure where the offending code lies? >>>>>>>>> >> Jack >>>>>>>>> > >>>>>>>>> > I don't know sorry. >>>>>>>>> > >>>>>>>>> > - Josh >>>>>>>>> >>>>>>>>>
