This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes

Bug 439168

Summary: xargs aborts at __assert_fail
Product: [Fedora] Fedora Reporter: Mamoru TASAKA <mtasaka>
Component: findutilsAssignee: Vitezslav Crhonek <vcrhonek>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: adam, bruno, esm, jakub, john.ellson, mail, oliva, richard, sangu.fedora, silfreed, stickster, valdis.kletnieks, vcrhonek
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-03-28 09:43:28 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mamoru TASAKA 2008-03-27 09:18:04 EDT
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 (
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
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/ symbols from
Loaded symbols for /lib/
Reading symbols from /lib/ symbols from
Loaded symbols for /lib/
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 
[root@localhost ~]# rpm -q glibc
Comment 1 Mamoru TASAKA 2008-03-27 09:18:39 EDT
Which glibc-2.7.90-9 this issue does not happen.
Comment 2 Jakub Jelinek 2008-03-27 10:07:35 EDT
What does
getconf ARG_MAX
ulimit -s
For 2.6.23+ kernels glibc returns `ulimit -s` / 4, as that's those kernels use
as argument size limit.
Comment 3 Mamoru TASAKA 2008-03-27 10:17:20 EDT
[root@localhost i386]# getconf ARG_MAX
[root@localhost i386]# ulimit -s
Comment 4 Mamoru TASAKA 2008-03-27 10:27:02 EDT
Note that current glibc is 2.7.90-9.
Comment 5 Jakub Jelinek 2008-03-27 10:47:12 EDT
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);
assert(bc_ctl.arg_max <= (ARG_MAX-2048));
which of course fails if sysconf (_SC_ARG_MAX) > ARG_MAX.
Comment 6 Orion Poplawski 2008-03-27 10:58:29 EDT
*** Bug 439184 has been marked as a duplicate of this bug. ***
Comment 7 Jakub Jelinek 2008-03-27 12:34:21 EDT
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.
Comment 8 Paul W. Frields 2008-03-27 12:43:01 EDT
Jakub, is that release note-worthy?
Comment 9 Jakub Jelinek 2008-03-27 12:47:41 EDT
No, fortunately ARG_MAX isn't used in too many programs.  I'll post about it to
fedora-devel-list though.
Comment 10 John Ellson 2008-03-28 11:41:48 EDT
This problem also breaks graphviz builds on x86_64
Comment 11 Paul W. Frields 2008-03-29 13:21:35 EDT
*** Bug 439610 has been marked as a duplicate of this bug. ***