mosh-server crashed with SIGSEGV in execute_helper()

Bug #1561621 reported by Anders Kaseorg
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
glibc (Ubuntu)
Confirmed
Medium
Unassigned
mosh (Debian)
Fix Released
Unknown
mosh (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

mosh-server in Xenial crashes immediately on startup. This is a glibc bug, but a Mosh workaround was committed upstream. See

https://github.com/mobile-shell/mosh/issues/727
https://bugs.debian.org/817929
https://sourceware.org/ml/libc-help/2016-03/msg00004.html
https://sourceware.org/bugzilla/show_bug.cgi?id=19861

ProblemType: Crash
DistroRelease: Ubuntu 16.04
Package: mosh 1.2.5-1.1build1
ProcVersionSignature: Ubuntu 4.4.0-15.31-generic 4.4.6
Uname: Linux 4.4.0-15-generic x86_64
NonfreeKernelModules: openafs
ApportVersion: 2.20-0ubuntu3
Architecture: amd64
CurrentDesktop: GNOME
Date: Thu Mar 24 12:22:08 2016
Disassembly: => 0x0: Cannot access memory at address 0x0
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/mosh-server
InstallationDate: Installed on 2016-02-19 (34 days ago)
InstallationMedia: Ubuntu-GNOME 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160218)
ProcCmdline: mosh-server
SegvAnalysis:
 Segfault happened at: 0x0: Cannot access memory at address 0x0
 PC (0x00000000) not located in a known VMA region (needed executable region)!
SegvReason: executing NULL VMA
Signal: 11
SourcePackage: mosh
StacktraceTop:
 ?? ()
 ?? () from /usr/lib/x86_64-linux-gnu/libutempter.so.0
 utempter_add_record () from /usr/lib/x86_64-linux-gnu/libutempter.so.0
 ?? ()
 __libc_start_main (main=0x564683ff2000, argc=1, argv=0x7fff22b44308, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff22b442f8) at ../csu/libc-start.c:291
Title: mosh-server crashed with SIGSEGV in utempter_add_record()
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm bumblebee cdrom dip libvirtd lpadmin plugdev sambashare sbuild sudo wireshark

Revision history for this message
In , Goffredo Baroncelli (kreijack) wrote :

I encountered this bug because mosh stopped to work after debian updated the libc to the 2.22 [1][2]. After few tests I discovered that the problem was related to a strange combination of switch and libs (see below).

The minimal test case to reproduce the problem is the following:

$ cat boom.c
extern void dofork();

int main() {
 dofork();
}

$ cat dofork.c
#include <unistd.h>

void dofork() {
 fork();
}

$ gcc -fPIC -c dofork.c
$ gcc -shared -Wl,-z,now -o libdofork.so dofork.o
$ gcc -o boom boom.c -lpthread -L$(pwd) -ldofork
$ LD_LIBRARY_PATH=$(pwd) ./boom
Segmentation fault

Expected result: the program doesn't have to crash
Result: the program crashes :-)

The fatal combination seems to be "-lpthread", "-Wl,-z,now" a call to fork() and the glibc-2.22. The crash happens near the fork.

The bug happened in mosh because:
- mosh is linked against libprotobuffer and libutempter
- mosh uses the "-Wl,-z,now" switch
- libprotobuffer via pkg-config suggests the -lpthread switch
- and libutempter uses the fork() function.
Together created the condition for the bug.

Looking at the commits between the 2.21 and 2.22 regarding nptl/pt-fork.c, I found the following one:

   commit beff1d132c16aedd87a3f1bc7b572c8e69819015
   Author: Roland McGrath <email address hidden>
   Date: Fri Feb 6 10:53:07 2015 -0800

        Clean up NPTL fork to be compat-only

Reverting it, the problem seems to disappear.

Florian Weimer, made some further investigation:

(gdb) break dofork
Breakpoint 1 at 0x4005b0
(gdb) r
Starting program: /home/fweimer/boom
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Breakpoint 1, 0x00007ffff79bd6d4 in dofork () from
/home/fweimer/libdofork.so
(gdb) disassemble
Dump of assembler code for function dofork:
   0x00007ffff79bd6d0 <+0>: push %rbp
   0x00007ffff79bd6d1 <+1>: mov %rsp,%rbp
=> 0x00007ffff79bd6d4 <+4>: callq 0x7ffff79bd5c0 <fork@plt>
   0x00007ffff79bd6d9 <+9>: nop
   0x00007ffff79bd6da <+10>: pop %rbp
   0x00007ffff79bd6db <+11>: retq
End of assembler dump.
(gdb) si
0x00007ffff79bd5c0 in fork@plt () from /home/fweimer/libdofork.so
(gdb) disassemble
Dump of assembler code for function fork@plt:
=> 0x00007ffff79bd5c0 <+0>: jmpq *0x200a0a(%rip) #
0x7ffff7bbdfd0 <email address hidden>
   0x00007ffff79bd5c6 <+6>: pushq $0x2
   0x00007ffff79bd5cb <+11>: jmpq 0x7ffff79bd590
End of assembler dump.
(gdb) print *(void **)0x7ffff7bbdfd0
$1 = (void *) 0x0
(gdb)

The commit beff1d132c16aedd87a3f1bc7b572c8e69819015,
assumes that __libc_fork has been relocated before the IFUNC resolver
for the libpthread fork definition runs, which is not always true.

Florian

----------------------------------
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817929
[2] https://github.com/mobile-shell/mosh/issues/727

Revision history for this message
Anders Kaseorg (andersk) wrote :
description: updated
Anders Kaseorg (andersk)
information type: Private → Public
Revision history for this message
Apport retracing service (apport) wrote :

StacktraceTop:
 ?? ()
 execute_helper (master_fd=master_fd@entry=5, argv=argv@entry=0x7fff22b43700) at iface.c:110
 utempter_add_record (master_fd=5, hostname=<optimized out>) at iface.c:146
 run_server (with_motd=true, verbose=false, colors=0, command_argv=0x7fff22b43860, command_path=..., desired_port=<optimized out>, desired_ip=<optimized out>) at mosh-server.cc:498
 main (argc=<optimized out>, argv=<optimized out>) at mosh-server.cc:322

Revision history for this message
Apport retracing service (apport) wrote : Stacktrace.txt
Revision history for this message
Apport retracing service (apport) wrote : StacktraceSource.txt
Revision history for this message
Apport retracing service (apport) wrote : ThreadStacktrace.txt
Changed in glibc (Ubuntu):
importance: Undecided → Medium
summary: - mosh-server crashed with SIGSEGV in utempter_add_record()
+ mosh-server crashed with SIGSEGV in execute_helper()
tags: removed: need-amd64-retrace
Changed in mosh (Debian):
status: Unknown → Fix Released
Revision history for this message
Anders Kaseorg (andersk) wrote :

We can bring in the Mosh workaround by syncing from Debian (bug 1561680).

Revision history for this message
In , Anders Kaseorg (andersk) wrote :

To reproduce on Ubuntu 16.04, I had to add -Wl,--no-as-needed before -lpthread (to make sure the resulting binary really links libpthread.so.0).

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in glibc (Ubuntu):
status: New → Confirmed
Changed in mosh (Ubuntu):
status: New → Confirmed
Revision history for this message
In , Florian Weimer (fweimer) wrote :

It turns out the IFUNC handler is not an optimization in the vfork case. A tail call is required there because the vfork implementation has to make sure that it can return twice even if the stack has been clobbered (which is why the return address is loaded into a register in the i386 and x86_64 implementations).

Revision history for this message
Logan Rosen (logan) wrote :

This should be fixed by mosh 1.2.5-2, which I just synced.

Revision history for this message
Anders Kaseorg (andersk) wrote :

Confirmed fixed in mosh 1.2.5-2 (but the glibc bug is still reproducible).

Changed in mosh (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
In , Florian Weimer (fweimer) wrote :
Revision history for this message
In , Andrew Travneff (travneff) wrote :

Created attachment 9285
fork() called from TCL

Hi all,
Have something similar with fork() called from TCL code (interpreter built from OpenEmbedded).
fork() call in TCL lib returns __libc_fork address instead of child pid. It works like fork() is directly replaced with fork_resolve().
More info attached. Can't reproduce in another way for now.

Can it be fixed/workarounded in a way better than disabling pthreads for TCL?

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via f06f3f05b48c72e2c9b0fa78671f94fd22d67da8 (commit)
      from 7838d298d895f65247fb6b498db03a4336fc0506 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=f06f3f05b48c72e2c9b0fa78671f94fd22d67da8

commit f06f3f05b48c72e2c9b0fa78671f94fd22d67da8
Author: Florian Weimer <email address hidden>
Date: Wed Jun 1 07:14:42 2016 +0200

    fork in libpthread cannot use IFUNC resolver [BZ #19861]

    This commit only addresses the fork case, the vfork case has to be a
    tail call, which is why the generic code needs an IFUNC resolver
    there.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 9 +++++++++
 nptl/pt-fork.c | 43 ++++++++++---------------------------------
 2 files changed, 19 insertions(+), 33 deletions(-)

Revision history for this message
In , Florian Weimer (fweimer) wrote :

I'm marking this as fixed because the reported fork issue has been addressed. The remaining vfork issue is now bug 20188.

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.23/master has been updated
       via 1915d6d182a55d1eb852643a78ac24bc17783fb0 (commit)
      from e6eea05ee7bc49dbe9531620595fd7f6ca587dcd (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=1915d6d182a55d1eb852643a78ac24bc17783fb0

commit 1915d6d182a55d1eb852643a78ac24bc17783fb0
Author: Florian Weimer <email address hidden>
Date: Wed Jun 1 07:14:42 2016 +0200

    fork in libpthread cannot use IFUNC resolver [BZ #19861]

    This commit only addresses the fork case, the vfork case has to be a
    tail call, which is why the generic code needs an IFUNC resolver
    there.

    (cherry picked from commit f06f3f05b48c72e2c9b0fa78671f94fd22d67da8)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 9 +++++++++
 nptl/pt-fork.c | 43 ++++++++++---------------------------------
 2 files changed, 19 insertions(+), 33 deletions(-)

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.22/master has been updated
       via a79b262c1e68098701da6ac34bd1ba8ca8413961 (commit)
      from 444fb8c27d9b0d1671ce1a441faf52b24305a332 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=a79b262c1e68098701da6ac34bd1ba8ca8413961

commit a79b262c1e68098701da6ac34bd1ba8ca8413961
Author: Florian Weimer <email address hidden>
Date: Wed Jun 1 07:14:42 2016 +0200

    fork in libpthread cannot use IFUNC resolver [BZ #19861]

    This commit only addresses the fork case, the vfork case has to be a
    tail call, which is why the generic code needs an IFUNC resolver
    there.

    (cherry picked from commit f06f3f05b48c72e2c9b0fa78671f94fd22d67da8)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 9 +++++++++
 nptl/pt-fork.c | 43 ++++++++++---------------------------------
 2 files changed, 19 insertions(+), 33 deletions(-)

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :
Download full text (51.8 KiB)

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The annotated tag, glibc-2.24 has been created
        at beb0f59498c3e0337df298f9d7a3f8f77eb39842 (tag)
   tagging fdfc9260b61d3d72541f18104d24c7bcb0ce5ca2 (commit)
  replaces glibc-2.23
 tagged by Carlos O'Donell
        on Mon Aug 1 22:46:26 2016 -0400

- Log -----------------------------------------------------------------
The GNU C Library
=================

The GNU C Library version 2.24 is now available.

The GNU C Library is used as *the* C library in the GNU system and
in GNU/Linux systems, as well as many other systems that use Linux
as the kernel.

The GNU C Library is primarily designed to be a portable
and high performance C library. It follows all relevant
standards including ISO C11 and POSIX.1-2008. It is also
internationalized and has one of the most complete
internationalization interfaces known.

The GNU C Library webpage is at http://www.gnu.org/software/libc/

Packages for the 2.24 release may be downloaded from:
        http://ftpmirror.gnu.org/libc/
        http://ftp.gnu.org/gnu/libc/

The mirror list is at http://www.gnu.org/order/ftp.html

NEWS for version 2.24
=====================

* The minimum Linux kernel version that this version of the GNU C Library
  can be used with is 3.2, except on i[4567]86 and x86_64, where Linux
  kernel version 2.6.32 or later suffices (on architectures that already
  required kernel versions more recent than 3.2, those requirements remain
  unchanged). Linux 3.2 or later kernel headers are required on all
  architectures.

* The pap_AN locale has been deleted. This has been deprecated for a long
  time. It has been replaced by pap_AW & pap_CW, both of which have long
  been included in previous releases.

* The readdir_r and readdir64_r functions have been deprecated. It is
  recommended to use readdir and readdir64 instead.

* The type “union wait” has been removed. It was deprecated in the early
  1990s and never part of POSIX. Application code should use the int type
  instead of “union wait”.

* A new NSS action is added to facilitate large distributed system
  administration. The action, MERGE, allows remote user stores like LDAP
  to be merged into local user stores like /etc/groups in order to provide
  easy to use, updated, and managed sets of merged credentials. The new
  action can be used by configuring it in /etc/nsswitch.conf:
  group: files [SUCCESS=merge] nis
  Implemented by Stephen Gallagher (Red Hat).

* The deprecated __malloc_initialize_hook variable has been removed from the
  API.

* The long unused localedef --old-style option has been removed. It hasn't
  done anything in over 16 years. Scripts using this option can safely
  drop it.

* nextupl, nextup, nextupf, nextdownl, nextdown and nextdownf are added to
  libm. They are defined by TS 18661 and IEEE754-2008. The nextup functions
  return the next representable value in the direction of positive infinity
  and the nextdown functions return the next representable value in the
  direction of negative infi...

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, gentoo/2.23 has been updated
       via 7331d984691b31a1c43bae54f4596a37fd9e7dcb (commit)
      from 36234ceda21820d2f874067553e7faae763a40cf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7331d984691b31a1c43bae54f4596a37fd9e7dcb

commit 7331d984691b31a1c43bae54f4596a37fd9e7dcb
Author: Florian Weimer <email address hidden>
Date: Wed Jun 1 07:14:42 2016 +0200

    fork in libpthread cannot use IFUNC resolver [BZ #19861]

    This commit only addresses the fork case, the vfork case has to be a
    tail call, which is why the generic code needs an IFUNC resolver
    there.

    (cherry picked from commit f06f3f05b48c72e2c9b0fa78671f94fd22d67da8)
    (cherry picked from commit 1915d6d182a55d1eb852643a78ac24bc17783fb0)

-----------------------------------------------------------------------

Summary of changes:
 nptl/pt-fork.c | 43 ++++++++++---------------------------------
 1 files changed, 10 insertions(+), 33 deletions(-)

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via fc5ad7024c620cdfe9b76e94638aac83b99c5bf8 (commit)
      from 852d63120783fae5bf85a067320dc4ba1ed59f11 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=fc5ad7024c620cdfe9b76e94638aac83b99c5bf8

commit fc5ad7024c620cdfe9b76e94638aac83b99c5bf8
Author: Andreas Schwab <email address hidden>
Date: Tue Aug 8 16:21:58 2017 +0200

    Don't use IFUNC resolver for longjmp or system in libpthread (bug 21041)

    Unlike the vfork forwarder and like the fork forwarder as in bug 19861,
    there won't be a problem when the compiler does not turn this into a tail
    call.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 6 ++++++
 nptl/pt-longjmp.c | 31 ++++++++++---------------------
 nptl/pt-system.c | 24 ++++++++----------------
 3 files changed, 24 insertions(+), 37 deletions(-)

Changed in glibc:
importance: Unknown → Medium
status: Unknown → Fix Released
Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.26/master has been updated
       via 71170eba2af41e08d51cf9d7b1ded5fd4b0b5c9c (commit)
       via 4db8f362c13c7239311db95bd7f96d4bce0769f3 (commit)
       via 88758c4ad3f046d050bc2c3ae0f172b6524ca6c2 (commit)
      from 6850e9c6bad862a1b982f456096c54946c2aaeab (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=71170eba2af41e08d51cf9d7b1ded5fd4b0b5c9c

commit 71170eba2af41e08d51cf9d7b1ded5fd4b0b5c9c
Author: Andreas Schwab <email address hidden>
Date: Tue Aug 8 17:44:32 2017 +0200

    Add test for bug 21041

    (cherry picked from commit 40c06a3d0450365e9675fe26f34fc56ce8497325)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=4db8f362c13c7239311db95bd7f96d4bce0769f3

commit 4db8f362c13c7239311db95bd7f96d4bce0769f3
Author: Andreas Schwab <email address hidden>
Date: Wed Aug 9 10:36:08 2017 +0200

    Fix s390 version of pt-longjmp.c

    (cherry picked from commit 5797b410a87f6f6f6d3661d730fac320cbd5f270)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=88758c4ad3f046d050bc2c3ae0f172b6524ca6c2

commit 88758c4ad3f046d050bc2c3ae0f172b6524ca6c2
Author: Andreas Schwab <email address hidden>
Date: Tue Aug 8 16:21:58 2017 +0200

    Don't use IFUNC resolver for longjmp or system in libpthread (bug 21041)

    Unlike the vfork forwarder and like the fork forwarder as in bug 19861,
    there won't be a problem when the compiler does not turn this into a tail
    call.

    (cherry picked from commit fc5ad7024c620cdfe9b76e94638aac83b99c5bf8)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 21 +++++++++++++
 nptl/Makefile | 6 ++-
 nptl/pt-longjmp.c | 31 ++++++-------------
 nptl/pt-system.c | 24 +++++----------
 .../lcong48.c => nptl/tst-compat-forwarder-mod.c | 10 ++++--
 .../tst-compat-forwarder.c | 23 ++++++--------
 sysdeps/unix/sysv/linux/s390/pt-longjmp.c | 4 +-
 7 files changed, 61 insertions(+), 58 deletions(-)
 copy stdlib/lcong48.c => nptl/tst-compat-forwarder-mod.c (77%)
 copy math/test-fe-snans-always-signal.c => nptl/tst-compat-forwarder.c (67%)

Revision history for this message
In , Cvs-commit (cvs-commit) wrote :

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, release/2.25/master has been updated
       via 0e6f64d9d04a9a26a048d1fb1bf1ebdb6739c5af (commit)
       via 06e775f4646f823cb858f50258bbe5a6f1e6bbe1 (commit)
       via 8182ccd9b8f9e6474712ddc904930e150f96da36 (commit)
      from 46acbd0582ce0c1b661e1b43f8e783daeea6ed9a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0e6f64d9d04a9a26a048d1fb1bf1ebdb6739c5af

commit 0e6f64d9d04a9a26a048d1fb1bf1ebdb6739c5af
Author: Andreas Schwab <email address hidden>
Date: Tue Aug 8 17:44:32 2017 +0200

    Add test for bug 21041

    (cherry picked from commit 40c06a3d0450365e9675fe26f34fc56ce8497325)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=06e775f4646f823cb858f50258bbe5a6f1e6bbe1

commit 06e775f4646f823cb858f50258bbe5a6f1e6bbe1
Author: Andreas Schwab <email address hidden>
Date: Wed Aug 9 10:36:08 2017 +0200

    Fix s390 version of pt-longjmp.c

    (cherry picked from commit 5797b410a87f6f6f6d3661d730fac320cbd5f270)

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=8182ccd9b8f9e6474712ddc904930e150f96da36

commit 8182ccd9b8f9e6474712ddc904930e150f96da36
Author: Andreas Schwab <email address hidden>
Date: Tue Aug 8 16:21:58 2017 +0200

    Don't use IFUNC resolver for longjmp or system in libpthread (bug 21041)

    Unlike the vfork forwarder and like the fork forwarder as in bug 19861,
    there won't be a problem when the compiler does not turn this into a tail
    call.

    (cherry picked from commit fc5ad7024c620cdfe9b76e94638aac83b99c5bf8)

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog | 21 +++++++++++++
 nptl/Makefile | 6 ++-
 nptl/pt-longjmp.c | 31 ++++++-------------
 nptl/pt-system.c | 24 +++++----------
 .../lcong48.c => nptl/tst-compat-forwarder-mod.c | 10 ++++--
 .../tst-compat-forwarder.c | 23 ++++++--------
 sysdeps/unix/sysv/linux/s390/pt-longjmp.c | 4 +-
 7 files changed, 61 insertions(+), 58 deletions(-)
 copy stdlib/lcong48.c => nptl/tst-compat-forwarder-mod.c (77%)
 copy math/test-fe-snans-always-signal.c => nptl/tst-compat-forwarder.c (67%)

Revision history for this message
In , Woxok75306 (woxok75306) wrote :

Glad this one is sorted had some problems at https://www.frankstontreeremoval.com.au

Revision history for this message
In , Zacmanken (zacmanken) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.