In message <20220213055846.a3cd1...@slippy.cwsent.com>, Cy Schubert writes:
> In message <f2bb296b-fada-6fd1-d466-983d469f0...@radscan.com>, Jon Trulson
> writ
> es:
> > This is a multi-part message in MIME format.
> > --------------EpVlcJBAf2vaQEetU12bQc1D
> > Content-Type: text/plain; charset=UTF-8; format=flowed
> > Content-Transfer-Encoding: 8bit
> >
> > On 2/12/22 22:13, Cy Schubert wrote:
> > > In message<556ade25-7889-556d-0d43-8f8901750...@radscan.com>, Jon Trulson
> > > writ
> > > es:
> > >> Hi,
> > [...]
> > >> Patches are always welcome.
> > > Thanks.
> > >
> > > I just fixed a dtinfogen issue on FreeBSD 14-CURRENT. This is the same
> > > issue discussed on OpenBSD 6.8 here,https://sourceforge.net/p/cdesktopenv
> /t
> > > ickets/94/. By default FreeBSD 14-CURRENT enabled jemalloc() debug mode,
> > > which by default enables newly malloc()ed memory to be initialized with
> > > junk. This in turn causes "flex scanner jammed" under FreeBSD current bui
> lt
> > > without MALLOC_PRODUCTION=yes in /etc/src.conf. To mitigate the problem o
> ne
> > > needs to add MALLOC_CONF=junk:false to the make environment prior to buil
> d.
> > >
> > > This affected 14-CURRENT (actually any -CURRENT as it affected 13-CURRENT
> > > prior to this but is fine under 13-STABLE).
> > >
> > > The problem does not exist under FreeBSD 13-STABLE nor under 12-STABLE
> > > because jemalloc() is configured without debugging options, like
> > > opt.junk:true.
> > >
> > > I suspect that the OpenBSD bug is probably the same bug. They may
> > > initialize newly allocated heap to junk just as FreeBSD -CURRENT does.
> > >
> > > You can see what I did on FreeBSD here,
> > > https://cgit.FreeBSD.org/ports/commit/?id=50324bba317cf1f58e8c434e0e2ed12
> 9c
> > d
> > > ed3887.
> >
> > That is interesting...
> >
> > I just committed a pile of patches from Liang Chang today that converts
> > the docs to be UTF-8, and reworks much of the underlying code and
> > infrastructure - fixing a lot of problems and improving things there
> > quite a bit.
> >
> > When/if you get a chance, could you tell me how well current master
> > fares on FreeBSD 14? I only have 12 and 13 in my current build testing
> > pool.
>
> At the moment I am running ports/x11/cde, which is 2.4.0. I haven't managed
> to get the yet to be committed ports/x11/cde-devel (which will track your
> master) to completely build. It builds but when it packages it puts files
> where they are not expected so the ports infrastructure QA (when used in
> DEVELOPER mode) complains -- meaning that it will never package.
>
> >
> > Otherwise, I'll see how to enable that in Makefile.am or configure when
> > I get more time.
>
> I've enabled it in the port, but that only fixes FreeBSD.
>
> I don't use OpenBSD so I cannot speak definitively about it but a brief
> look at their src/lib/libc/stdlib suggests they don't use jemalloc, but
> phkmalloc (originally written for FreeBSD in 1995 and later replaced in
> FreeBSD by jemalloc, because jemalloc is multithreaded while phkmalloc is
> not). phkmalloc has similar options to fill memory with junk as jemalloc
> does, but they're named and configured differently. Without digging into
> their source code too deeply, I suspect that OpenBSD may have enabled the
> junk option by default. Given that OpenBSD produces the same "flex scanner
> jammed" message I'd think that this would be a safe assumption.
>
> (Whereas FreeBSD only enables the junk option in our git main development
> branch, currently 14-CURRENT.)
>
> I'll get working on the x11/cde-devel port this week again. I was
> sidetracked by some other FreeBSD projects I was working on and had to put
> x11/cde-devel on the back burner. Hopefully I can resolve the packaging
> issues this week.
To add another thought. I was toying with the idea of replacing all
malloc() with calloc() in dtinfo or at the very least replacing it in
dtinfogen. The difference between malloc() and calloc() is the latter zero
fills memory. A calloc(1, size_t) is the same as malloc(size_t). The "1"
means allocate one instance of the second argument. Long term this is
probably a better solution than the make environment hack. I put it here
because after receiving an email from another FreeBSD developer just
moments ago I'm more convinced this is the path forward.
>From the malloc(3) man page:
The calloc() function allocates space for number objects, each size
bytes in length. The result is identical to calling malloc() with an
argument of number * size, with the exception that the allocated
memory
is explicitly initialized to zero bytes.
--
Cheers,
Cy Schubert <cy.schub...@cschubert.com>
FreeBSD UNIX: <c...@freebsd.org> Web: https://FreeBSD.org
NTP: <c...@nwtime.org> Web: https://nwtime.org
The need of the many outweighs the greed of the few.
_______________________________________________
cdesktopenv-devel mailing list
cdesktopenv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
