pymol crashing under Qt on Catalina

Jack Howarth howarth.at.macports at gmail.com
Mon Oct 14 21:52:58 UTC 2019


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/20191014/f5c4f595/attachment-0001.html>


More information about the macports-dev mailing list