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 - glibc: wait4 cannot handle NULL rusage arguments
Summary: glibc: wait4 cannot handle NULL rusage arguments
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Carlos O'Donell
QA Contact: Fedora Extras Quality Assurance
: 1824307 (view as bug list)
Depends On:
Blocks: ARMTracker x86Tracker 1818011
TreeView+ depends on / blocked
Reported: 2020-04-09 06:21 UTC by Zdenek Dohnal
Modified: 2020-10-05 08:31 UTC (History)
16 users (show)

Fixed In Version: glibc-2.31.9000-9.fc33
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-04-21 14:22:24 UTC
Type: Bug

Attachments (Terms of Use)

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. ***

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