Bug 439168

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

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 (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

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
print?
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
131072
[root@localhost i386]# ulimit -s
10240

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);
asserts:
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. ***