Re: HEADSUP: /etc/malloc.conf format change
On Wed, Apr 25, 2012 at 10:43:59AM -0700, Jason Evans wrote: On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote: So you removed _malloc_options that was part of the documented programming API, while some software made use of it. [...] 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. A __FreeBSD_version bump seems like a good idea to me, but adding backward compatibility for _malloc_options is questionable at best. Of the 17 options that _malloc_options supported, only 6 have directly corresponding options in malloc_conf, plus another 3 that would present strange quirks (fragile and difficult to precisely document) if an attempt were made to provide compatibility. In past iterations I was always careful to provide as much option compatibility as possible over the lifetime of each release (e.g., 'H' in RELENG_7), but individual options came and went with major releases. _malloc_options could only be pushed so far, and when it hit its breaking point I replaced it. Creaky compatibility is IMO a liability rather than an asset. In the case of nginx, it looks like a __FreeBSD_version bump is exactly what it needs. I'll try to get that done today. Well, thanks for that, and for all your hard work with malloc(). On a related note, is there any way to find all ports that refer to _malloc_options without extracting source for all of them? I considered being proactive about finding software that depends on _malloc_options, but no tractable approaches came to mind. That was already answered by Mark. -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: /etc/malloc.conf format change
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 r...@freebsd.org FreeBSD committer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: /etc/malloc.conf format change
On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote: 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. A __FreeBSD_version bump seems like a good idea to me, but adding backward compatibility for _malloc_options is questionable at best. Of the 17 options that _malloc_options supported, only 6 have directly corresponding options in malloc_conf, plus another 3 that would present strange quirks (fragile and difficult to precisely document) if an attempt were made to provide compatibility. In past iterations I was always careful to provide as much option compatibility as possible over the lifetime of each release (e.g., 'H' in RELENG_7), but individual options came and went with major releases. _malloc_options could only be pushed so far, and when it hit its breaking point I replaced it. Creaky compatibility is IMO a liability rather than an asset. In the case of nginx, it looks like a __FreeBSD_version bump is exactly what it needs. I'll try to get that done today. On a related note, is there any way to find all ports that refer to _malloc_options without extracting source for all of them? I considered being proactive about finding software that depends on _malloc_options, but no tractable approaches came to mind. Thanks, Jason___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: /etc/malloc.conf format change
On Apr 25, 2012, at 10:43 AM, Jason Evans wrote: On a related note, is there any way to find all ports that refer to _malloc_options without extracting source for all of them? I considered being proactive about finding software that depends on _malloc_options, but no tractable approaches came to mind. Yes, there actually is. The Ports maintainers will run experimental ports builds on the port build clusters to help verify potentially disruptive changes like this before they are committed. Ask on ports@ for more details. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADSUP: /etc/malloc.conf format change
On Wed, Apr 25, 2012 at 09:37:36PM -0700, Tim Kientzle wrote: The Ports maintainers will run experimental ports builds on the port build clusters to help verify potentially disruptive changes like this before they are committed. Well, actually, portmgr@. Send a PR with [exp-run] in the Synopsis and assign it to portmgr. We are slowly trying to get caught up, now that we have new hardware. mcl ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADSUP: /etc/malloc.conf format change
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. Jason___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
No man page for /etc/malloc.conf ?
Where can I find the definitions for the AJ, aj, HR, etc. that are being discussed in the 'performance' thread? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: No man page for /etc/malloc.conf ?
Hello, Where can I find the definitions for the AJ, aj, HR, etc. that are being discussed in the 'performance' thread? In malloc(3): http://www.freebsd.org/cgi/man.cgi?query=mallocapropos=0sektion=0manpath=FreeBSD+5.0-currentformat=html man malloc --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
malloc.conf (was Re: Performance problems with 5.0-RELEASE)
Dan Nelson wrote: # ls -l /etc/malloc.conf lrwxr-xr-x 1 root wheel 4 Jan 23 11:52 /etc/malloc.conf - HR H and should only make a difference if you are low on memory. Yes. R is on by default in 5.0 anyway, due to A and J being on by default. That's not what the malloc(3) man page suggests -- R seems to have nothing to do with A or J. Perhaps, however, the improvement I see is due to turning off A and J (implicitly, ie by not specifying them)? - Rahul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc.conf (was Re: Performance problems with 5.0-RELEASE)
On Thu, Jan 23, 2003 at 02:14:46PM -0500, Rahul Siddharthan wrote: Dan Nelson wrote: # ls -l /etc/malloc.conf lrwxr-xr-x 1 root wheel 4 Jan 23 11:52 /etc/malloc.conf - HR H and should only make a difference if you are low on memory. Yes. R is on by default in 5.0 anyway, due to A and J being on by default. That's not what the malloc(3) man page suggests -- R seems to have nothing to do with A or J. Perhaps, however, the improvement I see is due to turning off A and J (implicitly, ie by not specifying them)? Read again. J automatically sets R. Yes, not having J set should improve performance noticeably compared with having J set. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: malloc.conf (was Re: Performance problems with 5.0-RELEASE)
In the last episode (Jan 23), Rahul Siddharthan said: Dan Nelson wrote: # ls -l /etc/malloc.conf lrwxr-xr-x 1 root wheel 4 Jan 23 11:52 /etc/malloc.conf - HR H and should only make a difference if you are low on memory. Yes. R is on by default in 5.0 anyway, due to A and J being on by default. That's not what the malloc(3) man page suggests -- R seems to have nothing to do with A or J. Perhaps, however, the improvement I see is due to turning off A and J (implicitly, ie by not specifying them)? The description for J says This options also sets the R option (heh. found a typo :), and inside malloc.c, the internal flags representing A and J are set to 1. Not specifying [aA] or [jJ] leaves them at the defaults, so they should still be enabled if you have HR set. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
malloc.conf
After upgrading to 4.0 from source, I had a simple program which called malloc core dump on me. After ktrace'ing it and creating /etc/malloc.conf it was happier. But I can't find malloc.conf anywhere in /usr/src. How does it get created during the build ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc.conf
On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote: Please read the malloc(3) manual page. I did and created malloc.conf as documented there. And things were fine after that. Wouldn't it be better if the build process created a default /etc/malloc.conf ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc.conf
In message [EMAIL PROTECTED], Arun Sharma writes: On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote: Please read the malloc(3) manual page. I did and created malloc.conf as documented there. And things were fine after that. Wouldn't it be better if the build process created a default /etc/malloc.conf ? Exactly how did you create it ? -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc.conf
I did and created malloc.conf as documented there. And things were fine after that. Wouldn't it be better if the build process created a default /etc/malloc.conf ? It's purely an optional file; one doesn't need to be installed by default in order for things to behave as expected. Consider it a debugging feature. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc.conf
On Sat, Mar 25, 2000 at 09:05:18PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Arun Sharma writes: On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote: Please read the malloc(3) manual page. I did and created malloc.conf as documented there. And things were fine after that. Wouldn't it be better if the build process created a default /etc/malloc.conf ? Exactly how did you create it ? Just as it is documented: ln -s 'A' /etc/malloc.conf -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc.conf
In message [EMAIL PROTECTED], Arun Sharma writes: On Sat, Mar 25, 2000 at 09:05:18PM +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Arun Sharma writes: On Sat, Mar 25, 2000 at 08:55:16PM +0100, Poul-Henning Kamp wrote: Please read the malloc(3) manual page. I did and created malloc.conf as documented there. And things were fine after that. Wouldn't it be better if the build process created a default /etc/malloc.conf ? Exactly how did you create it ? Just as it is documented: ln -s 'A' /etc/malloc.conf And that made your program not dump core ? In that case you should rather try: ln -sf 'AJ' /etc/malloc.conf and fix the bug in your program. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: malloc.conf
On Sat, Mar 25, 2000 at 12:11:50PM -0800, Jordan K. Hubbard wrote:
I did and created malloc.conf as documented there. And things were
fine after that. Wouldn't it be better if the build process created
a default /etc/malloc.conf ?
It's purely an optional file; one doesn't need to be installed by
default in order for things to behave as expected. Consider it
a debugging feature.
You're right. It works for the default case. I was doing an unsupported
operation: experimenting with rfork and the clone() call from Linuxthreads
port.
However, the mere presence of clone() in the same executable
makes malloc unhappy.
8668 test CALL readlink(0x280f1114,0xbfbff7b8,0x3f)
8668 test NAMI "/etc/malloc.conf"
8668 test RET readlink -1 errno 2 No such file or directory
8668 test CALL sigprocmask(0x1,0x2806,0x28060010)
8668 test RET sigprocmask 0
8668 test CALL sigprocmask(0x3,0x28060010,0)
8668 test RET sigprocmask 0
8668 test PSIG SIGSEGV SIG_DFL
8668 test NAMI "test.core"
The program is:
#include stdio.h
#include unistd.h
#include stdlib.h
#include sys/types.h
#include sys/wait.h
main()
{
int status;
pid_t pid;
void *stack;
stack = malloc(4096);
}
It works fine stand alone. But when linked with some other stuff, it core
dumps. If I create /etc/malloc.conf, it's ok.
-Arun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
