Description of problem: [root@localhost ~]# ulimit -c unlimited [root@localhost ~]# which true | xargs rpm -qf xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed. Aborted (core dumped) [root@localhost ~]# ls -al core.* -rw------- 1 root root 286720 Mar 27 22:06 core.4503 [root@localhost ~]# gdb xargs core.4503 GNU gdb Fedora (6.7.50.20080227-3.fc9) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... warning: Can't read pathname for load map: Input/output error. Reading symbols from /lib/libc-2.7.90.so...Reading symbols from /usr/lib/debug/lib/libc-2.7.90.so.debug...done. done. Loaded symbols for /lib/libc-2.7.90.so Reading symbols from /lib/ld-2.7.90.so...Reading symbols from /usr/lib/debug/lib/ld-2.7.90.so.debug...done. done. Loaded symbols for /lib/ld-2.7.90.so Core was generated by `xargs rpm -qf'. Program terminated with signal 6, Aborted. [New process 4503] #0 0x00131402 in __kernel_vsyscall () (gdb) bt #0 0x00131402 in __kernel_vsyscall () #1 0x0015d4b0 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x0015ee78 in abort () at abort.c:88 #3 0x0015653e in __assert_fail (assertion=0x804cab4 "bc_ctl.arg_max <= (131072-2048)", file=0x804cfa5 "xargs.c", line=443, function=0x804d390 "main") at assert.c:78 #4 0x0804a545 in main (argc=3, argv=0xbfbfb384) at xargs.c:443 (gdb) qui [root@localhost ~]# rpm -q findutils findutils-4.2.33-1.fc9.i386 [root@localhost ~]# rpm -q glibc glibc-2.7.90-12.i686
Which glibc-2.7.90-9 this issue does not happen.
What does getconf ARG_MAX print? ulimit -s ? For 2.6.23+ kernels glibc returns `ulimit -s` / 4, as that's those kernels use as argument size limit.
[root@localhost i386]# getconf ARG_MAX 131072 [root@localhost i386]# ulimit -s 10240
Note that current glibc is 2.7.90-9.
urrent glibc is 2.7.90-12, not -9. Anyway, the bug is in xargs, the assert is bogus. With the 2.6.23+ kernels sysconf (_SC_ARG_MAX) can return large value than ARG_MAX macro. While bc_get_arg_max handles that correctly, xargs.c instead of asserting say assert(bc_ctl.arg_max <= bc_ctl.posix_arg_size_max); or (more expensive): assert(bc_ctl.arg_max <= bc_get_arg_max() - 2048); asserts: assert(bc_ctl.arg_max <= (ARG_MAX-2048)); which of course fails if sysconf (_SC_ARG_MAX) > ARG_MAX.
*** Bug 439184 has been marked as a duplicate of this bug. ***
Next rawhide glibc will #undef ARG_MAX, which is more POSIXly correct and for findutils just a rebuild will be needed (though the assert is still a bad idea, otherwise whenever some OS changes from a fixed arg size limit to a dynamic one xargs will need rebuild), though it can break other programs which use ARG_MAX incorrectly (google codesearch e.g. showed arla, some ksh variants, etc.). Programs should use sysconf (_SC_ARG_MAX) if ARG_MAX is not defined, and _SC_ARG_MAX is defined.
Jakub, is that release note-worthy?
No, fortunately ARG_MAX isn't used in too many programs. I'll post about it to fedora-devel-list though.
This problem also breaks graphviz builds on x86_64
*** Bug 439610 has been marked as a duplicate of this bug. ***