pymol crashing under Qt on Catalina

Jack Howarth howarth.at.macports at gmail.com
Wed Oct 16 23:36:27 UTC 2019 

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.macports at 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.macports at 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.macports at 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.macports at 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 <jonesc at hep.phy.cam.ac.uk>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 13 Oct 2019, at 4:57 pm, Jack Howarth <
>>>>> howarth.at.macports at 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.macports at 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 <
>>>>>> jonesc at hep.phy.cam.ac.uk> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 13 Oct 2019, at 4:02 pm, Jack Howarth <
>>>>>>> howarth.at.macports at 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.macports at 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 <
>>>>>>>> jonesc at hep.phy.cam.ac.uk> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > On 13 Oct 2019, at 3:11 pm, Joshua Root <jmr at macports.org>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > On 2019-10-14 00:59 , Jack Howarth wrote:
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >>> On Sun, Oct 13, 2019 at 9:49 AM Chris Jones <
>>>>>>>>> jonesc at hep.phy.cam.ac.uk
>>>>>>>>> >>> <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>
>>>>>>>>> >>>    On 13 Oct 2019, at 2:46 pm, Joshua Root <jmr at macports.org
>>>>>>>>> >>>    <mailto:jmr at 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
>>>>>>>>>
>>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191016/7fd45d14/attachment-0001.html>

More information about the macports-dev mailing list