Bug 208154 - please increase ARG_MAX
Summary: please increase ARG_MAX
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
Depends on:
Reported: 2016-03-20 10:56 UTC by Jon Boden
Modified: 2019-11-04 20:10 UTC (History)
4 users (show)

See Also:

Increase ARG_MAX (489 bytes, patch)
2016-03-20 10:56 UTC, Jon Boden
no flags Details | Diff
LibreOffice build failure (4.97 KB, text/plain)
2016-03-29 20:40 UTC, Jon Boden
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jon Boden 2016-03-20 10:56:46 UTC
Created attachment 168420 [details]
Increase ARG_MAX

ARG_MAX is too small for building LibreOffice (errors out with "Argument list too long").

This was found when attempting to build the pre-packaged Ubuntu version of LibreOffice on ubuntuBSD (FreeBSD derivative).

I suggest increasing it to match with the Linux value.
Comment 1 Jon Boden 2016-03-20 10:57:45 UTC
Just for reference, the one from Linux is:

$ getconf ARG_MAX
Comment 2 Pedro F. Giffuni freebsd_committer 2016-03-20 19:03:05 UTC
For reference, here are some values in other systems:

#define ARG_MAX	(256 * 1024) /* max bytes for an exec function */ 

#define	_ARG_MAX32	1048320	/* max length of args to exec 32-bit program */
#define	_ARG_MAX64	2096640	/* max length of args to exec 64-bit program */
#ifdef	_LP64
#define	ARG_MAX		_ARG_MAX64	/* max length of arguments to exec */
#else	/* _LP64 */
#define	ARG_MAX		_ARG_MAX32	/* max length of arguments to exec */
#endif	/* _LP64 */


I have no opinion, but since our own LibreOffice builds haven't seem to have reached that issue(?), perhaps it's better to avoid a huge bump in that value.
Perhaps the _ARG_MAX32 is sufficient for UbuntuBSD? (Cool project BTW).
Comment 3 Konstantin Belousov freebsd_committer 2016-03-21 05:01:39 UTC
ARG_MAX sizes the exec_map submap, the current formula is 16 * round_page(PATH_MAX + ARG_MAX).  Increasing ARG_MAX would consume (much) more KVA on KVA-starved architectures, basically all 32bits, esp. PAE-like configs.

I believe that this was discussed at least once, with Andrey (?).
Comment 4 Andriy Gapon freebsd_committer 2016-03-21 07:56:08 UTC
(In reply to Konstantin Belousov from comment #3)
No, I was not aware of this issue and I do not have insights into the situation, sorry.
Comment 5 Jon Boden 2016-03-21 10:18:28 UTC
(In reply to Konstantin Belousov from comment #3)

So it could be increased on 64-bit architectures only?

P.S. I'm preparing the test with 1048320 as requested by Pedro

P.P.S. Btw we've been running a heavy load amd64 system (builder machine) with the initial patch for months and haven't found stability issues so far.
Comment 6 Jon Boden 2016-03-22 00:39:56 UTC
Btw I've been suggested that --enable-mergelibs might be the reason "Argument list too long" only happens in some cases:

Comment 7 Pedro F. Giffuni freebsd_committer 2016-03-22 05:02:13 UTC
(In reply to Jon Boden from comment #6)

Ah yes, and I should say that the mergelibs option is a rather bad idea ... but I am biased because I am a developer in Apache OpenOffice and we never considered it in the first place ;).

Since it affects only one port and it has been worked around, I am rather happy about not bumping the default.
Comment 8 Jon Boden 2016-03-29 20:40:55 UTC
Created attachment 168767 [details]
LibreOffice build failure


The result of my test: increasing it to 1048320 as Pedro suggested is enough to make LibreOffice build succeed.

Note: Removing --enable-mergelibs does NOT work around the problem. The only way I managed to build LibreOffice (Ubuntu version 1:5.0.2-0ubuntu1) is by increasing ARG_MAX.
Comment 9 Pedro F. Giffuni freebsd_committer 2016-06-28 02:49:59 UTC
(In reply to Jon Boden from comment #8)

Sorry for the late reply ...

More than not enabling mergelibs, you have to explicitly disable it. 
Our LibreOffice port does that:


Not sure how Debian does but I suspect they also have it building.

I can't really justify changing the FreeBSD value for one port where
we manage to workaround the issue.

I will close the issue for now but it is a good reference for the future.
Thanks for testing!