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