<div dir="ltr"><div>Hi Ken,</div><div><br></div>I have a cygwin installation so I updated it and checked both the usual w32api build and the UNIX build<div>with gcc-9.2.0. The w32api build works fine but I was able to reproduce the problem using a normal UNIX build.</div><div><br></div><div>Based on the fact that only replacing stable_sort with sort on line 286 of arrayop.h made the error disappear</div><div>but only forcing compare2<T> to return true did not, it was starting to look like a bug in the STL stable_sort</div><div>routine. But then I realized that I had inadvertently compiled against version 8.0.4 of the Boehm gc garbage collector</div><div>and I know that that version doesn't work under cygwin. The latest working version is 7.6.2, as you will</div><div>notice in the file build-scripts/build-asymptote.dos. So I recompiled with that and everything is fine. A simple test is:</div><div><br></div><div>./asy -dir base</div><div> sort(new string[][] {{"a","9"}});<br></div><div><br>Or you can just run </div><div>make check</div><div><br></div><div>So this is a problem with Boehm gc under cygwin; just switch to version 7.6.2 and you should be fine:</div><div><br></div><div>make clean</div><div>./configure --enable-gc=7.6.2</div><div><br></div><div>Regards,</div><div><br></div><div>-- John</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 5, 2020 at 7:45 PM Ken Brown <<a href="mailto:kbrow1i@gmail.com" target="_blank">kbrow1i@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/5/2020 6:53 PM, Nelson H. F. Beebe wrote:<br>
> Ken Brown <<a href="mailto:kbrow1i@gmail.com" target="_blank">kbrow1i@gmail.com</a>> reports a failure in building Asymptote<br>
> on Cygwin with gcc-9.2.0 (newly upgraded from gcc-7.4.x):<br>
> <br>
>>> When I build asy with this compiler it crashes in the sort2 test.<br>
>>> Running the test under gdb shows that there's a null pointer<br>
>>> dereference in GC_free (hhdr is null). If I build without<br>
>>> optimization, the problem doesn't occur.<br>
> <br>
> I just scanned all of the asy executables available at<br>
> <br>
> <a href="http://www.math.utah.edu/pub/texlive-utah/bin" rel="noreferrer" target="_blank">http://www.math.utah.edu/pub/texlive-utah/bin</a><br>
> <br>
> and found that TeX Live 2020 for these files were built with a gcc-9.x<br>
>>> compiler:<br>
> <br>
> amd64-clonos19/asy GCC: (FreeBSD Ports Collection) 9.2.0<br>
> amd64-freebsd130/asy GCC: (FreeBSD Ports Collection) 9.2.0<br>
> amd64-hardenedbsd13/asy GCC: (FreeBSD Ports Collection) 9.1.0<br>
> x86_64-arco19/asy GCC: (GNU) 9.2.0<br>
> x86_64-blackarch/asy GCC: (GNU) 9.2.0<br>
> x86_64-budgie1910/asy GCC: (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008<br>
> x86_64-centos8/asy GCC: (GNU) 9.1.1 20190605 (Red Hat 9.1.1-2)<br>
> x86_64-fedora30/asy GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)<br>
> x86_64-fedora31/asy GCC: (GNU) 9.2.1 20190827 (Red Hat 9.2.1-1)<br>
> x86_64-kali-2/asy GCC: (Debian 9.2.1-25) 9.2.1 20200123<br>
> x86_64-kaos2020/asy GCC: (GNU) 9.2.0<br>
> x86_64-manjaro19/asy GCC: (GNU) 9.2.1 20200130 GCC: (Arch Linux 9.2.1+20200130-2) 9.2.1 20200130<br>
> x86_64-openmandriva41-clang/asy GCC: (GNU) 9.2.1 20191109 (OpenMandriva) GCC: (GNU) 9.2.1 20191207 (OpenMandriva)<br>
> x86_64-openmandriva41/asy GCC: (GNU) 9.2.1 20191109 (OpenMandriva) GCC: (GNU) 9.2.1 20191207 (OpenMandriva)<br>
> x86_64-opensusetw2/asy GCC: (SUSE Linux) 9.2.1 20190903 [gcc-9-branch revision 275330]<br>
> x86_64-oracle8/asy GCC: (GNU) 9.1.1 20190605 (Red Hat 9.1.1-2)<br>
> x86_64-slackware15/asy GCC: (GNU) 9.2.0<br>
> x86_64-trident-void-linux/asy GCC: (GNU) 9.1.0 GCC: (GNU) 9.2.0<br>
> x86_64-ubuntu1910/asy GCC: (Ubuntu 9.2.1-9ubuntu2) 9.2.1 20191008<br>
> x86_64-ubuntu2004/asy GCC: (Ubuntu 9.2.1-21ubuntu1) 9.2.1 20191130<br>
> <br>
> With rare exceptions, I do not supply optimization levels when I build<br>
> TeX Live snapshots, and I don't install a build at the above URL if<br>
> there are segmentation faults in the build.<br>
> <br>
> Thus, I'm surprised by Ken's report, and it looks like something that<br>
> we need to figure out what is happening.<br>
> <br>
> Ken's report didn't mention the Asymptote version. As of yesterday's<br>
> source tree update, it is 2.64. Almost all of my builds, except for<br>
> the NetBSD systems, have been with Asymptote version 2.62 or 2.63.<br>
> <br>
> ----------------------------------------<br>
> <br>
> P.S. I note that gcc-8.4.0 was officially released yesterday, and many<br>
> O/S distributions allow installation of multiple major versions of gcc<br>
> and clang, without name conflicts. I typically install all of them on<br>
> our test lab machiens, and I've done thousands of builds of gcc and<br>
> scores of clang, from source code on our systems. Thus, that<br>
> compiler, if available on Cygwin, would be an alternative. It is<br>
> already in the Ubuntu 20.04 package system, as I found when I updated<br>
> one of our 20.04 systems this morning. Its announcement claimed<br>
> over 200 bug fixes compared to gcc-8.3.0.<br>
<br>
Thanks, Nelson, and thanks to everyone else who replied. It seems that this <br>
issue is specific to the Cygwin build of gcc-9.2.0.<br>
</blockquote></div>