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