pymol crashing under Qt on Catalina
Jack Howarth
howarth.at.macports at gmail.com
Wed Oct 16 00:50:13 UTC 2019
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/20191015/3453d561/attachment-0001.html>
More information about the macports-dev
mailing list