Bug 1418978 (glibc-7.4-support-backport) - glibc: backport upstream support/ directory
Summary: glibc: backport upstream support/ directory
Alias: glibc-7.4-support-backport
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: glibc
Version: 7.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Florian Weimer
QA Contact: Sergey Kolosov
Depends On:
Blocks: 1413146 1228114
TreeView+ depends on / blocked
Reported: 2017-02-03 10:36 UTC by Florian Weimer
Modified: 2017-08-01 18:09 UTC (History)
6 users (show)

Fixed In Version: glibc-2.17-162.el7
Doc Type: No Doc Update
Doc Text:
Clone Of:
Last Closed: 2017-08-01 18:09:25 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2017:1916 0 normal SHIPPED_LIVE Moderate: glibc security, bug fix, and enhancement update 2017-08-01 18:05:43 UTC
Sourceware 19469 0 None None None 2019-07-11 12:40:24 UTC
Sourceware 19648 0 None None None 2019-07-11 12:40:24 UTC

Description Florian Weimer 2017-02-03 10:36:48 UTC
Upstream has a new test support framework in the support/ subdirectory.  Some of the backports come with tests which use these facilities.

I suggest we create two patches, one for the Makefile integration, and another one which creates support/ with the contents of the upstream master branch.  The second patch should be generated by a script.  Then we can re-create the patch each time we need new support/ functionality for a future test backport.

We should not change test-skeleton.c at this point.

Comment 3 Florian Weimer 2017-02-14 10:27:49 UTC
We should turn on -Werror=implicit-function-declaration.  Without it, some test cases based on current upstream's test-skeleton.c (not support/test-driver.c) will compile and link, but fail at run time with an obscure error.  This is caused by implicit function prototypes for functions actually returning pointers (such as xpthread_create).  The return value is truncated to an int, corrupting the pointer.

Some test cases have started to fail on current kernels because the kernel now enforces RLIMIT_DATA more aggressively.  We need this commit:

commit 900056024b75eae8b550d7fee1dec9e71f28344e
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Mar 7 13:48:47 2016 +0100

    test-skeleton.c: Do not set RLIMIT_DATA [BZ #19648]
    With older kernels, it is mostly ineffective because it causes malloc
    to switch from sbrk to mmap (potentially invalidating malloc testing
    compared to what real appliations do).  With newer kernels which
    have switched to enforcing RLIMIT_DATA for mmap as well, some test
    cases will fail in an unintended fashion because the limit which was
    set previously does not include room for all mmap mappings.

Comment 4 Florian Weimer 2017-02-14 10:35:16 UTC
We also need this change to support some malloc tests:

commit f690b56979dea81340a397c1b5e44827a6fb06e7
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Aug 2 17:01:02 2016 +0200

    malloc: Run tests without calling mallopt [BZ #19469]
    The compiled tests no longer refer to the mallopt symbol
    from their main functions.  (Some tests still call mallopt
    explicitly, which is fine.)

It is probably best to include this here because we are already updating test-skeleton.c.

Comment 7 errata-xmlrpc 2017-08-01 18:09:25 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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