<div dir="ltr"><div dir="ltr"><div dir="ltr">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.<br><div><br></div><div><a href="https://trac.macports.org/ticket/59358">https://trac.macports.org/ticket/59358</a><br></div><div><br></div><div> Jack</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 16, 2019 at 6:36 PM Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com">howarth.at.macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div> Jack</div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 15, 2019 at 8:50 PM Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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?<div> Jack</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 14, 2019 at 5:52 PM Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">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...</div><div dir="ltr"><br></div><div dir="ltr"><div dir="ltr">Thread 0 Crashed:: Dispatch queue: com.apple.main-thread</div><div dir="ltr">0 org.qt-project.QtCore <span style="white-space:pre-wrap"> </span>0x00000001081ac641 0x107ffd000 + 1766977</div><div dir="ltr">1 org.qt-project.QtCore <span style="white-space:pre-wrap"> </span>0x000000010808c6c3 QString::fromUtf16(unsigned short const*, int) + 53</div><div dir="ltr">2 QtCore.so <span style="white-space:pre-wrap"> </span>0x000000010990ff1d qpycore_PyObject_AsQString(_object*) + 24</div><div dir="ltr">3 QtCore.so <span style="white-space:pre-wrap"> </span>0x000000010990ff83 qpycore_qt_conf() + 91</div><div dir="ltr">4 QtCore.so <span style="white-space:pre-wrap"> </span>0x0000000109802965 qpycore_post_init(_object*) + 665</div><div dir="ltr">5 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104227b36 _PyImport_LoadDynamicModule + 150</div><div dir="ltr">6 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010422654d import_submodule + 285</div><div dir="ltr">7 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104225fde load_next + 270</div><div dir="ltr">8 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104224e5b PyImport_ImportModuleLevel + 843</div><div dir="ltr">9 org.python.python <span style="white-space:pre-wrap"> </span>0x00000001041fe8a9 builtin___import__ + 137</div><div dir="ltr">10 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104157f6e PyObject_CallFunction + 318</div><div dir="ltr">11 org.python.python <span style="white-space:pre-wrap"> </span>0x00000001042249c1 PyImport_Import + 353</div><div dir="ltr">12 org.python.python <span style="white-space:pre-wrap"> </span>0x00000001042227dc PyImport_ImportModule + 28</div><div dir="ltr">13 sip.so <span style="white-space:pre-wrap"> </span>0x000000010870512f sip_api_export_module + 82</div><div dir="ltr">14 QtGui.so <span style="white-space:pre-wrap"> </span>0x0000000107a3f78e initQtGui + 225</div><div dir="ltr">15 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104227b36 _PyImport_LoadDynamicModule + 150</div><div dir="ltr">16 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010422654d import_submodule + 285</div><div dir="ltr">17 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010422633f ensure_fromlist + 575</div><div dir="ltr">18 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104224f0f PyImport_ImportModuleLevel + 1023</div><div dir="ltr">19 org.python.python <span style="white-space:pre-wrap"> </span>0x00000001041fe8a9 builtin___import__ + 137</div><div dir="ltr">20 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104157dc1 PyObject_Call + 97</div><div dir="ltr">21 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104207f26 PyEval_EvalFrameEx + 16198</div><div dir="ltr">22 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203d44 PyEval_EvalCodeEx + 2004</div><div dir="ltr">23 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203562 PyEval_EvalCode + 34</div><div dir="ltr">24 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104223756 PyImport_ExecCodeModuleEx + 230</div><div dir="ltr">25 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104226a78 load_source_module + 968</div><div dir="ltr">26 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104226df1 load_package + 321</div><div dir="ltr">27 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010422654d import_submodule + 285</div><div dir="ltr">28 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104225fde load_next + 270</div><div dir="ltr">29 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104224e5b PyImport_ImportModuleLevel + 843</div><div dir="ltr">30 org.python.python <span style="white-space:pre-wrap"> </span>0x00000001041fe8a9 builtin___import__ + 137</div><div dir="ltr">31 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104157dc1 PyObject_Call + 97</div><div dir="ltr">32 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104207f26 PyEval_EvalFrameEx + 16198</div><div dir="ltr">33 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203d44 PyEval_EvalCodeEx + 2004</div><div dir="ltr">34 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203562 PyEval_EvalCode + 34</div><div dir="ltr">35 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104223756 PyImport_ExecCodeModuleEx + 230</div><div dir="ltr">36 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104226a78 load_source_module + 968</div><div dir="ltr">37 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010422654d import_submodule + 285</div><div dir="ltr">38 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010422633f ensure_fromlist + 575</div><div dir="ltr">39 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104224f0f PyImport_ImportModuleLevel + 1023</div><div dir="ltr">40 org.python.python <span style="white-space:pre-wrap"> </span>0x00000001041fe8a9 builtin___import__ + 137</div><div dir="ltr">41 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104157dc1 PyObject_Call + 97</div><div dir="ltr">42 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104207f26 PyEval_EvalFrameEx + 16198</div><div dir="ltr">43 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203d44 PyEval_EvalCodeEx + 2004</div><div dir="ltr">44 org.python.python <span style="white-space:pre-wrap"> </span>0x000000010420e96a fast_function + 106</div><div dir="ltr">45 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104209298 PyEval_EvalFrameEx + 21176</div><div dir="ltr">46 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203d44 PyEval_EvalCodeEx + 2004</div><div dir="ltr">47 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104203562 PyEval_EvalCode + 34</div><div dir="ltr">48 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104232131 PyRun_FileExFlags + 161</div><div dir="ltr">49 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104231c2f PyRun_SimpleFileExFlags + 751</div><div dir="ltr">50 org.python.python <span style="white-space:pre-wrap"> </span>0x0000000104249acf Py_Main + 3279</div><div dir="ltr">51 libdyld.dylib <span style="white-space:pre-wrap"> </span>0x00007fff6539d405 start + 1</div><div><br></div><div>So I guess rebuilding QtCore.so with -fno-stack-check is the next step.</div><div> Jack </div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 2:10 PM Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div> Jack</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 12:07 PM Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 13 Oct 2019, at 4:57 pm, Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Another data point. Rebuilding python27 with this addition to the Portfile...<div><br></div>if { ([vercmp ${os.major} 19] >= 0) && ([vercmp $xcodeversion 11.3] < 0) } {<br> if {[string match clang ${configure.compiler}]} {<br> configure.cc-append -fno-stack-check<br> }<br>}</div><div dir="ltr"><br></div><div>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?</div></div></div></div></div></blockquote><div><br></div>Maybe. Or perhaps this is something different to the stack check issue. ....<div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div> Jack</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 11:38 AM Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">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.<br><br># Workaround for test failure :-<br># > ./sblat2 < ./sblat2.dat<br># Program received signal SIGSEGV: Segmentation fault - invalid memory reference.<br># Current information is that this should be fixed in Xcode 11.2<br>if { ([vercmp ${os.major} 19] >= 0) && ([vercmp $xcodeversion 11.2] < 0) } {<br> if {[string match clang ${configure.compiler}]} {<br> configure.cc-append -fno-stack-check<br> }<br>}<br><br>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?</div><div> Jack</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 11:08 AM Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 13 Oct 2019, at 4:02 pm, Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">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...<div><br></div><div><p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < ./sblat2.dat</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build Program received signal SIGSEGV: Segmentation fault - invalid memory reference.</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build Backtrace for this error:</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build #0 0x1029863e4</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build #1 0x102985b06</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build #2 0x7fff688fab1c</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build /bin/sh: line 1: 22671 Segmentation fault: 11 OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 ./sblat2 < ./sblat2.dat</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build make[1]: *** [level2] Error 139</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">:info:build make[1]: *** Waiting for unfinished jobs....</span></p>
<p style="margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style="font-variant-ligatures:no-common-ligatures">: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'</span></p></div></div></div></div></blockquote><div><br></div>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.<div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-variant-ligatures:no-common-ligatures"><br></span></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 10:49 AM Jack Howarth <<a href="mailto:howarth.at.macports@gmail.com" target="_blank">howarth.at.macports@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr">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?<div> Jack</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 13, 2019 at 10:13 AM Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank">jonesc@hep.phy.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 13 Oct 2019, at 3:11 pm, Joshua Root <<a href="mailto:jmr@macports.org" target="_blank">jmr@macports.org</a>> wrote:<br>
> <br>
> On 2019-10-14 00:59 , Jack Howarth wrote:<br>
>> <br>
>> <br>
>>> On Sun, Oct 13, 2019 at 9:49 AM Chris Jones <<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank">jonesc@hep.phy.cam.ac.uk</a><br>
>>> <mailto:<a href="mailto:jonesc@hep.phy.cam.ac.uk" target="_blank">jonesc@hep.phy.cam.ac.uk</a>>> wrote:<br>
>>> <br>
>>> <br>
>>> <br>
>>> On 13 Oct 2019, at 2:46 pm, Joshua Root <<a href="mailto:jmr@macports.org" target="_blank">jmr@macports.org</a><br>
>>> <mailto:<a href="mailto:jmr@macports.org" target="_blank">jmr@macports.org</a>>> wrote:<br>
>>> <br>
>>> On 2019-10-14 00:35 , Chris Jones wrote:<br>
>>>> <br>
>>>> After that, my next guess would perhaps another issue related to the<br>
>>>> stack-check issue with Xcode 11. See e.g. the fix I added for<br>
>>>> OpenBLAS<br>
>>>> <br>
>>>> <a href="https://github.com/macports/macports-ports/commit/6e78e5c9495b4dc4e7e050fae2b41dd5b9accfdd#diff-a755de84ca7f97ab071328807d829e0b" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/commit/6e78e5c9495b4dc4e7e050fae2b41dd5b9accfdd#diff-a755de84ca7f97ab071328807d829e0b</a><br>
>>> <br>
>>> I'd be wary of removing a hardening measure and leaving it at that. It<br>
>>> could be revealing a genuine stack-smashing bug.<br>
>> <br>
>> Agreed. Accordingly to Jeremy though its a Xcode bug expected to be<br>
>> fixed in 11.2. Thats why I subsequently added a version check, see e.g.<br>
> <br>
> Ah, good to know. Do you have a link to Jeremy's statement out of curiosity?<br>
<br>
No I don’t, I only know this second hand from a comment by Ken...<br>
<br>
> <br>
>> <a href="https://github.com/macports/macports-ports/blob/master/math/OpenBLAS/Portfile" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/blob/master/math/OpenBLAS/Portfile</a><br>
>> <br>
>> Line 109.<br>
>> <br>
>>> <br>
>>> - Josh<br>
>> <br>
>> <br>
>> Josh,<br>
>> Does anyone know if this is already fixed in the posted Xcode 11.2<br>
>> beta 2? If so, would rebuilding the OpenBLAS package with it be<br>
>> sufficient or aren't we sure where the offending code lies?<br>
>> Jack<br>
> <br>
> I don't know sorry.<br>
> <br>
> - Josh<br>
<br>
</blockquote></div>
</blockquote></div>
</div></blockquote></div></div></blockquote></div>
</blockquote></div>
</div></blockquote></div></div></div></blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>