Re: [RFC PATCH v2 0/2] Remove --enable-obsolete-nsl --enable-obsolete-rpc

[Florian Weimer <fweimer@redhat.com>]

* Petr Vorel:

>> I'm still having issues with elf/tst-ldconfig-ld_so_conf-update when
>> running with both commits (it's ok when running only first commit).
>
> OK, I noticed core dump (can be reproduced):
> systemd-coredump[26018]: Process 26016 (ld-linux-x86-64) of user 1000 dumped core.
>
>            PID: 26016 (ld-linux-x86-64)
>            UID: 1000 (foo)
>            GID: 100 (users)
>         Signal: 6 (ABRT)
>      Timestamp: Fri 2020-06-05 18:41:54 CEST (16min ago)
>   Command Line: /home/foo/build/glibc/remove-rpc.v2.second-commit.2/elf/ld-linux-x86-64.so.2 --library-path /home/foo/build/glibc/remove-rpc.v2.second-commit.2:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/math:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/elf:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/dlfcn:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/nss:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/nis:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/rt:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/resolv:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/mathvec:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/support:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/crypt:/home/foo/build/glibc/remove-rpc.v2.second-commit.2/nptl /home/foo/build/glibc/remove-rpc.v2.second-commit.2/debug/tst-ssp-1
>     Executable: /home/foo/build/glibc/remove-rpc.v2.second-commit.2/elf/ld.so
>  Control Group: /user.slice/user-1000.slice/session-1.scope
>           Unit: session-1.scope
>          Slice: user-1000.slice
>        Session: 1
>      Owner UID: 1000 (foo)
>        Boot ID: bfef12e3ca2046009a97d35fb89674bc
>     Machine ID: 66e50c6d8dd0edc674b23b51586326ca
>       Hostname: dell5510
>        Storage: none
>        Message: Process 26016 (ld-linux-x86-64) of user 1000 dumped core.
> Coredump entry has no core attached (neither internally in the journal nor externally on disk).

This seems unrelated.  I think systemd-coredump ignores ulimit -c 0
(which we perform programatically in the test skeleton), to cover cases
like this where the process is expected to abort.  So you get a few
spurious reports like this one.

Thanks,
Florian