Re: git: 50324bba317c - main - x11/cde: Fix build under 14-CURRENT

In message <20220213060942.64EEE24D@slippy.cwsent.com>, Cy Schubert writes:
> 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.

I replied again to the cdedesktop developer about the idea of replacing 
malloc(3) with calloc(3). Either way I'm certainly considering adding this 
patch to the port.

BTW, I have a cde-devel port I'm working on locally. It builds fine however 
pkg-plist issues abound because due to a new build process in which they've 
replaced imake with GNU configure for some reason I have yet to discover 
why it stages files to ${STAGEDIR}/usr instead of ${STAGEDIR}/${LOCALBASE}/d
t. I could be fighting a Linuxsim that crept in.


-- 
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.