Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 1822468

Summary: glibc: wait4 cannot handle NULL rusage arguments
Product: [Fedora] Fedora Reporter: Zdenek Dohnal <zdohnal>
Component: glibcAssignee: Carlos O'Donell <codonell>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: anto.trande, aoliva,, codonell, dj, fweimer, law, mfabian, mhroncok, pfrankli, rjones, rth, sgallagh, siddhesh, sipoyare, vondruch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: glibc-2.31.9000-9.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-21 14:22:24 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 245418, 1489998, 1818011    

Description Zdenek Dohnal 2020-04-09 06:21:20 UTC

I have to tell at the start - I'm not sure whether it is issue of glibc, but make/xargs binaries (where segfaults seem to origin) are compiled with glibc, so maybe just they need to be fixed... but I rather file it on glibc first, because it was the only updated package between successful build and the failed one (at least in Vim) which IMO can cause the similar segfaults.

The several builds failed only on i686/armv7hl:

Vim - segfaults on make:

flocq - segfaults on remake:

nip2 - segfaults on configure:

rust-proc-macro-error - segfaults on xargs:

podman - segfaults on xargs:

lmod - segfaults on xargs:

Would you mind looking into the issue?

Comment 1 Miro Hrončok 2020-04-09 07:36:36 UTC
In the meantime, I'm running:

$ koji tag f33-pending glibc-2.31.9000-6.fc33
Created task 43153881
Watching tasks (this may be safely interrupted)...
43153881 tagBuild (noarch): free
43153881 tagBuild (noarch): free -> closed
  0 free  0 open  1 done  0 failed

43153881 tagBuild (noarch) completed successfully

However I'm never sure if this is enough.

Comment 2 Miro Hrončok 2020-04-09 07:47:25 UTC
Releng ticket to untag:

Comment 3 Miro Hrončok 2020-04-09 08:22:57 UTC
With glibc-2.31.9000-6.fc33 back in the buildroot, the problem seem to be gone (for now).

Comment 4 Florian Weimer 2020-04-09 15:58:55 UTC
The make failure looks like this (only happens with -jN if more than one target is built):

==46== Invalid write of size 4
==46==    at 0x4A8B4F9: valid_timeval64_to_timeval (time.h:367)
==46==    by 0x4A8B4F9: rusage64_to_rusage (resource.h:97)
==46==    by 0x4A8B4F9: wait4 (wait4.c:125)
==46==    by 0x4A8B2C9: waitpid (waitpid.c:38)
==46==    by 0x12104A: reap_children (in /usr/bin/make)
==46==    by 0x121D94: new_job (in /usr/bin/make)
==46==    by 0x1133C8: execute_file_commands (in /usr/bin/make)
==46==    by 0x12E33C: ??? (in /usr/bin/make)
==46==    by 0x12EE12: update_goal_chain (in /usr/bin/make)
==46==    by 0x11074A: main (in /usr/bin/make)
==46==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

This was reported on libc-alpha:

A fix is under review:

The patch needs a v3.

Comment 5 Florian Weimer 2020-04-14 16:37:28 UTC
Fix was pushed upstream:;a=commitdiff;h=00515ea3a15703a3d196c1d1bd372214abc990ad

So we a good to rebase glibc past this bug.

Comment 7 Miro Hrončok 2020-04-15 18:10:55 UTC
I'm seeing this again as well.

Comment 9 Florian Weimer 2020-04-15 18:13:04 UTC
Untag request:

I'm deeply sorry about this, I had a momentary lapse of judgement.

Comment 10 Stephen Gallagher 2020-04-15 19:24:53 UTC
*** Bug 1824307 has been marked as a duplicate of this bug. ***