Running getrusage in a C program using threads fails to report the usage of other threads, whether they be parent threads, sibling threads, or child threads. RedHat has some unidentified patch for this problem in RH9.x and RHES3. My testing reveals: * RedHat 8.x -- Main thread reports own time, child info missing Child thread reports own time, parent info missing * RedHat 9.x -- Main thread reports own time, childs info as child Child thread cannot report parent's information * RedHat ES3 -- Main thread reports own time, childs info as child Child thread cannot report parent's information * Gentoo 2004.03 -- Main thread reports own time, child info missing Child thread reports own time, parent info missing * FreeBSD 5.2 -- Main thread reports own and child time as self Child thread reports own and parent time as self I'd say that FreeBSD gets it right. Absent that, RH9/ES3's behavior is better than RH8/Gentoo. This is a glibc and/or a kernel bug. See http://sources.redhat.com/ml/bug-glibc/2001-01/msg00125.html for some historical information, but RedHat did not reply with any patch information, or the like. Reproducible: Always Steps to Reproduce: 1. Compile attached program 2. Execute 3. Note that child's usage is not included in parent's report Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7-gentoo-r7) ================================================================= System uname: 2.6.7-gentoo-r7 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.mirrored.ca/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib acpi alsa apache2 apm arts audiofile avi berkdb caps cdr crypt cscope cups curl dga directfb doc emacs encode esd ethereal fdftk flac foomaticdb gd gdbm gif gmp gnome gphoto2 gpm gtk gtk2 hardened imagemagick imlib java joystick jpeg kde lcms ldap lesstif libg++ libwww mad mbox mikmod mmx motif mozilla mpeg mysql ncurses nls nocardbus nocd oggvorbis opengl oss pam pdflib perl plotutils png postgres ppds prelude python qt quicktime readline samba sdl slang snmp socks5 speex spell sse ssl svga tcltk tcpd tetex theora tiff truetype unicode usb videos wmf x86 xinerama xml xml2 xmms xosd xv zlib"
Created attachment 35518 [details] Test program Compile with: gcc -o /tmp/x /tmp/x.c -lpthread There are several #defines which you may set to help check what is going on: -DFORK will execute the ``Juhuthread'' in a true child process, child's stats properly reported back to parent -DSKIPTHREAD will skip printing of ``Juhuthread'' information entirely -DINLINETHREAD will print ``Juhuthread'' in the parent's context with no thread/fork activity at all.
This looks like it may still be a problem. The mailing list linked to blames it on the kernel, any ideas on how we should handle this?
If, in your make.conf you have nptl (or perhaps nptl and nptlonly) it works correctly. My Gentoo system using original linuxthreads still has the older incorrect behavior. As such, we can probably close the ticket.
