Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 439168 - xargs aborts at __assert_fail
Summary: xargs aborts at __assert_fail
Alias: None
Product: Fedora
Classification: Fedora
Component: findutils
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Vitezslav Crhonek
QA Contact: Fedora Extras Quality Assurance
: 439184 439610 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2008-03-27 13:18 UTC by Mamoru TASAKA
Modified: 2008-03-29 17:21 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-03-28 13:43:28 UTC

Attachments (Terms of Use)

Description Mamoru TASAKA 2008-03-27 13:18:04 UTC
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 13:18:39 UTC
Which glibc-2.7.90-9 this issue does not happen.

Comment 2 Jakub Jelinek 2008-03-27 14:07:35 UTC
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 14:17:20 UTC
[root@localhost i386]# getconf ARG_MAX
[root@localhost i386]# ulimit -s

Comment 4 Mamoru TASAKA 2008-03-27 14:27:02 UTC
Note that current glibc is 2.7.90-9.

Comment 5 Jakub Jelinek 2008-03-27 14:47:12 UTC
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 14:58:29 UTC
*** Bug 439184 has been marked as a duplicate of this bug. ***

Comment 7 Jakub Jelinek 2008-03-27 16:34:21 UTC
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 16:43:01 UTC
Jakub, is that release note-worthy?

Comment 9 Jakub Jelinek 2008-03-27 16:47:41 UTC
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 15:41:48 UTC
This problem also breaks graphviz builds on x86_64

Comment 11 Paul W. Frields 2008-03-29 17:21:35 UTC
*** Bug 439610 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.