Date: Sat, 12 Feb 2022 22:09:42 -0800 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: Cy Schubert <cy@freebsd.org>, ports-committers@freebsd.org, dev-commits-ports-all@freebsd.org, dev-commits-ports-main@freebsd.org Subject: Re: git: 50324bba317c - main - x11/cde: Fix build under 14-CURRENT Message-ID: <20220213060942.64EEE24D@slippy.cwsent.com> In-Reply-To: <YgicFDckACibXNUY@FreeBSD.org> References: <202202130115.21D1FPPu025146@gitrepo.freebsd.org> <YgicFDckACibXNUY@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <YgicFDckACibXNUY@FreeBSD.org>, Alexey Dokuchaev writes: > On Sun, Feb 13, 2022 at 01:15:25AM +0000, Cy Schubert wrote: > > commit 50324bba317cf1f58e8c434e0e2ed129cded3887 > > > > x11/cde: Fix build under 14-CURRENT > > > > Under 14-CURRENT MALLOC_PRODUCTION is not set which puts malloc() into > > debug mode. In debug mode malloc() enables opt.junk to write junk to > > newly malloc()ed heap in order to help developers discover memory > > allocation bugs. Unfortunately CDE's dtinfogen assumes newly malloc()ed > > memory is zero filled (i.e. not filled with junk), resulting in > > "flex scanner jammed". > > Neat investigation, it gives a new angle for looking at -CURRENT-specific > build failures, but why not patch the CDE source code instead? malloc() > allocates uninitialized memory, it's generally unsafe to assume that it's > zero-filled in the first place. Also, MAKE_ENV hack is not upstreamable, > I'm afraid. :-) Actually, upstream is interested in this approach. One of their devs just emailed me ten minutes ago that that he may put it into their Makefile.am. I pointed to a cdedesktop PR for OpenBSD 6.7 with the same problem. OpenBSD uses phkmalloc. Considering it has the same error OpenBSD has enabled junk by default. I had been toying with the idea of replacing all malloc() with calloc() in dtinfo or at the very least dtinfogen. But at least this gets it building on a stock 14-CURRENT. Locally I use MALLOC_PRODUCTION=yes, which is why I could not reproduce the problem locally and my poudriere jails are built from my /usr/src (src= poudriere-jail option). Testing on a poudriere freebsdci jail confirmed the problem and allowed testing a fix. Yes, more work needs to be done. Any future patches will also be upstreamed. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220213060942.64EEE24D>