Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 25 Apr 2012 20:39:49 +0400
From:      Ruslan Ermilov <ru@FreeBSD.org>
To:        Jason Evans <jasone@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: HEADSUP: /etc/malloc.conf format change
Message-ID:  <20120425163949.GA53937@lo0.su>
In-Reply-To: <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org>
References:  <7FC153A1-8815-4BAE-AB94-FED51DBFFEAA@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 17, 2012 at 12:34:20PM -0700, Jason Evans wrote:
> As a result of the recent jemalloc update, the format for
> /etc/malloc.conf has changed.  If your system has an old-style
> /etc/malloc.conf, you will want to delete it prior to
> installworld, and optionally re-create it using the new format
> after rebooting.  See malloc.conf(5) for details (specifically
> the TUNING section and the "opt.*" entries in the MALLCTL
> NAMESPACE section).
> 
> The MALLOC_OPTIONS environment variable and the _malloc_options
> global do not pose the same headache, because their new
> counterparts are named MALLOC_CONF and malloc_conf,
> respectively.

So you removed _malloc_options that was part of the documented
programming API, while some software made use of it.

While removing part of the documented API was definitely a bad
idea, you didn't provide any mean to detect this change 
programmatically, neither through a macro test, nor by bumping
__FreeBSD_version.  The only way now is to try and see if it
compiles, which is far from perfect.

The way how _malloc_options is handled for binary compatibility,
by simply ignoring its value, is (ahem) questionable.

Why do I care?  The developers of the nginx web server have 
been notified today that it could not be built on FreeBSD
10.0-CURRENT anymore, due to this change, when compiled with 
"nginx malloc debugging".  It's activated by the DEBUG option
of the www/nginx-devel port, if you care to try it out.

Please explore the possibility to add backwards compatiblity for 
the documented API, or at the very least provide a mean to 
detect this otherwise disruptive and hard to detect change
for a programmer.


Cheers,
-- 
Ruslan Ermilov
ru@FreeBSD.org
FreeBSD committer



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120425163949.GA53937>