Debian Bug report logs - #817929
mosh fails to connect, giving a UDP error

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: demure <demure@sdf.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: mosh fails to connect, giving a UDP error

Date: Fri, 11 Mar 2016 12:53:07 -0500

Package: mosh
Version: 1.2.5-1.1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Mosh is unable to connect to debian sid's mosh-server currently. I have 
two instances of debian sid, a laptop and a VPS. Neither can connect to 
each other with mosh, or even them selfs with `mosh localhost`.
When attempting to do so, the follow error message is displayed:

----- (IP removed)
mosh did not make a successful connection to xxx.xxx.xxx.xxx:60001.
Please verify that UDP port 60001 is not firewalled and can reach the 
server.

(By default, mosh uses a UDP port between 60000 and 61000. The -p option
selects a specific UDP port number.)

[mosh is exiting.]
-----

I do not have any firewall rules that effect this, and tested with an 
empty iptables. I asked another user on #debian-next, and they confirm 
the same issue on their install.

Now, mosh-client does work, as I can mosh into a server not running 
debain sid.

Thank you
-demure


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.5-x86_64-linode61 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mosh depends on:
ii  dpkg            1.18.4
ii  libc6           2.22-2
ii  libgcc1         1:5.3.1-11
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.2     1.0.2g-1
ii  libstdc++6      5.3.1-11
ii  libtinfo5       6.0+20160213-1
ii  libutempter0    1.1.6-3
ii  openssh-client  1:7.2p2-1
ii  zlib1g          1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  perl-base [libio-socket-ip-perl]  5.22.1-8

mosh suggests no packages.

-- no debconf information

Message #10 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Goffredo Baroncelli <kreijack@gmail.com>

To: Debian Bug Tracking System <817929@bugs.debian.org>

Subject: Re: mosh fails to connect, giving a UDP error

Date: Fri, 11 Mar 2016 21:17:28 +0100

[Message part 1 (text/plain, inline)]

Package: mosh
Version: 1.2.5-1.1
Followup-For: Bug #817929

I can confirm that. After a recent update (but I was sure which one) mosh stops to work.

The problem seems to be in mosh-server which ends with a SIGSEGV after it forks:

$ strace -f mosh-server 
execve("/usr/bin/mosh-server", ["mosh-server"], [/* 23 vars */]) = 0
brk(NULL)                               = 0x5614e69fc000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f9e62de8000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=191871, ...}) = 0
mmap(NULL, 191871, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f9e62db9000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
[...]
[...]
mprotect(0x7f9e600e7000, 4096, PROT_READ) = 0
mprotect(0x7f9e602f9000, 4096, PROT_READ) = 0
munmap(0x7f9e62d81000, 191871)          = 0
open("/etc/group", O_RDONLY|O_CLOEXEC)  = 6
lseek(6, 0, SEEK_CUR)                   = 0
fstat(6, {st_mode=S_IFREG|0644, st_size=1105, ...}) = 0
mmap(NULL, 1105, PROT_READ, MAP_SHARED, 6, 0) = 0x7f9e62de6000
lseek(6, 1105, SEEK_SET)                = 1105
munmap(0x7f9e62de6000, 1105)            = 0
close(6)                                = 0
ioctl(5, TIOCSPTLCK, [0])               = 0
ioctl(5, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(5, TIOCGPTN, [7])                 = 0
stat("/dev/pts/7", {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 7), ...}) = 0
open("/dev/pts/7", O_RDWR|O_NOCTTY)     = 6
ioctl(6, TIOCSWINSZ, {ws_row=45, ws_col=115, ws_xpixel=0, ws_ypixel=0}) = 0
clone(strace: Process 18446 attached
child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f9e62db1a10) = 18446
[pid 18446] set_robust_list(0x7f9e62db1a20, 24) = 0
[pid 18445] close(6 <unfinished ...>
[pid 18446] close(5 <unfinished ...>
[pid 18445] <... close resumed> )       = 0
[pid 18446] <... close resumed> )       = 0
[pid 18445] rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER|SA_RESTART, 0x7f9e62468d30},  <unfinished ...>
[pid 18446] setsid( <unfinished ...>
[pid 18445] <... rt_sigaction resumed> {SIG_DFL, [], 0}, 8) = 0
[pid 18446] <... setsid resumed> )      = 18446
[pid 18445] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
[pid 18446] ioctl(6, TIOCSCTTY, 0)      = 0
[pid 18446] dup2(6, 0)                  = 0
[pid 18446] dup2(6, 1)                  = 1
[pid 18446] dup2(6, 2)                  = 2
[pid 18446] close(6)                    = 0
[pid 18446] rt_sigaction(SIGHUP, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f9e62468d30}, NULL, 8) = 0
[pid 18446] --- SIGHUP {si_signo=SIGHUP, si_code=SI_KERNEL} ---
[pid 18445] +++ killed by SIGSEGV +++
+++ killed by SIGHUP +++


Enclose you can find the full strace.


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.4 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mosh depends on:
ii  dpkg            1.18.4
ii  libc6           2.22-2
ii  libgcc1         1:6-20160220-1
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.2     1.0.2g-1
ii  libstdc++6      6-20160220-1
ii  libtinfo5       6.0+20160213-1
ii  libutempter0    1.1.6-3
ii  openssh-client  1:7.2p2-1
ii  zlib1g          1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  perl-base [libio-socket-ip-perl]  5.22.1-8

mosh suggests no packages.

-- no debconf information

[strace-mosh (text/plain, attachment)]

Message #15 received at 817929@bugs.debian.org (full text, mbox, reply):

From: wh <microrffr@gmail.com>

To: 817929@bugs.debian.org

Date: Fri, 11 Mar 2016 23:55:28 -0800

[Message part 1 (text/plain, inline)]

I have the same problem. I found that in dmesg, there were several lines
about mosh-server crashing by segfault, for example:

[ 2980.423340] mosh-server[7104]: segfault at 0 ip (null) sp bfd4bb6c error
14 in mosh-server[80001000+58000]

Here's some info from running mosh-server in GDB. I don't have debugging
symbols though. I'm on i386 unstable.

(gdb) c
Continuing.

mosh-server (mosh 1.2.5) [build mosh 1.2.5]
Copyright 2012 Keith Winstein <mosh-devel@mit.edu>
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[mosh-server detached, pid = 7803]
[New process 7817]
[Thread debugging using libthread_db enabled]
Using host libthread_db library
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
Reading symbols from
/usr/lib/debug/.build-id/c6/7504492553f5afa0f618b16c92503a945af3ea.debug...done.
Reading symbols from
/usr/lib/debug/.build-id/af/a2e42e2dbf1580b3978c0810f5f4e930f3a24e.debug...done.
Reading symbols from
/usr/lib/debug/.build-id/7b/6848177dab9b5cd74f85e7dfa158bed12f5e3e.debug...done.
Reading symbols from
/usr/lib/debug/.build-id/25/b9bceb62bd6179ae5ad4bbbd9a8e612ce4189a.debug...done.

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xb7be786c in ?? () from /usr/lib/i386-linux-gnu/libutempter.so.0
#2  0xb7be79d3 in utempter_add_record () from
/usr/lib/i386-linux-gnu/libutempter.so.0
#3  0x80006d59 in main ()
(gdb) info share
From        To          Syms Read   Shared Object Library
0xb7fa4240  0xb7fb03a4  Yes (*)     /lib/i386-linux-gnu/libtinfo.so.5
0xb7ec1910  0xb7f60784  Yes (*)     /usr/lib/i386-linux-gnu/libprotobuf.so.9
0xb7e62890  0xb7e70241  Yes
/lib/i386-linux-gnu/i686/cmov/libpthread.so.0
0xb7e04f70  0xb7e487b4  Yes (*)
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.2
0xb7c51a40  0xb7d7a6b4  Yes (*)
/usr/lib/i386-linux-gnu/i686/cmov/libcrypto.so.1.0.2
0xb7c08a30  0xb7c09326  Yes
/lib/i386-linux-gnu/i686/cmov/libutil.so.1
0xb7bec8f0  0xb7bfd122  Yes (*)     /lib/i386-linux-gnu/libz.so.1
0xb7be76c0  0xb7be7b64  Yes (*)     /usr/lib/i386-linux-gnu/libutempter.so.0
0xb7ae3290  0xb7b90de4  Yes (*)     /usr/lib/i386-linux-gnu/libstdc++.so.6
0xb7a2d5a0  0xb7a5ec5f  Yes         /lib/i386-linux-gnu/i686/cmov/libm.so.6
0xb7a0e080  0xb7a237d5  Yes (*)     /lib/i386-linux-gnu/libgcc_s.so.1
0xb786b600  0xb7997fbd  Yes         /lib/i386-linux-gnu/i686/cmov/libc.so.6
0xb7fdc830  0xb7ff4930  Yes         /lib/ld-linux.so.2
0xb784ea30  0xb784f961  Yes         /lib/i386-linux-gnu/i686/cmov/libdl.so.2
0xb7fcce00  0xb7fd1613  Yes
/lib/i386-linux-gnu/i686/cmov/libnss_compat.so.2
0xb7690110  0xb769bd11  Yes
/lib/i386-linux-gnu/i686/cmov/libnsl.so.1
0xb7681960  0xb7687c50  Yes
/lib/i386-linux-gnu/i686/cmov/libnss_nis.so.2
0xb766ea50  0xb76749c2  Yes
/lib/i386-linux-gnu/i686/cmov/libnss_files.so.2
(*): Shared library is missing debugging information.

[Message part 2 (text/html, inline)]

Message #20 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Goffredo Baroncelli <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: libutempter related problem ?

Date: Sat, 12 Mar 2016 16:11:01 +0100

It seems that the problem is related  to libutempter0. If commenting the call in the source of mosh-server, the problem disappear...

Message #25 received at 817929@bugs.debian.org (full text, mbox, reply):

From: wh <microrffr@gmail.com>

To: "817929@bugs.debian.org" <817929@bugs.debian.org>

Date: Sat, 12 Mar 2016 22:21:43 +0000

[Message part 1 (text/plain, inline)]

(can't see my previous message. resending.)
#0  0x00000000 in ?? ()
#1  0xb7be786c in execute_helper (master_fd=master_fd@entry=5,
argv=argv@entry=0xbfffebbc) at iface.c:110
#2  0xb7be79d3 in utempter_add_record (master_fd=5, hostname=0xbffff28c
"mosh [3749]") at iface.c:146
#3  0x80006d59 in run_server (with_motd=<optimized out>, verbose=<optimized
out>, colors=<optimized out>, command_argv=<optimized out>,
    command_path="/bin/bash", desired_port=<optimized out>,
desired_ip=<optimized out>) at mosh-server.cc:498
#4  main (argc=<optimized out>, argv=0xbffff494) at mosh-server.cc:322

http://sources.debian.net/src/libutempter/1.1.6-3/iface.c/#L110
SIGSEGV for calling fork()? I can't figure this out.

[Message part 2 (text/html, inline)]

Message #30 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Goffredo Baroncelli <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: mosh and libutempter

Date: Tue, 15 Mar 2016 22:08:59 +0100

I am not sure that libutempter0 is the real culprit, however I find a very strange behavior:

If I preload libutempter mosh-server didn't crashes. Instead if I run mosh-server alone, it crashes:


$ ldd /usr/bin/mosh-server 
	linux-vdso.so.1 (0x00007ffce553b000)
	libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f8966678000)
	libprotobuf.so.9 => /usr/lib/x86_64-linux-gnu/libprotobuf.so.9 (0x00007f896634e000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f8966130000)
	libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007f8965ec7000)
	libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007f8965a64000)
	libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f8965860000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f8965645000)
-->	libutempter.so.0 => /usr/lib/x86_64-linux-gnu/libutempter.so.0 (0x00007f8965442000)
	libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f89650be000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8964dc0000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f8964baa000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f8964805000)
	/lib64/ld-linux-x86-64.so.2 (0x0000561792d06000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8964601000)


$ /usr/bin/mosh-server 

In dmesg I got "mosh-server[8320]: segfault at 0 ip...."


Instead if I do

$ LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libutempter.so.0 /usr/bin/mosh-server

mosh-server didn't crash...

I am inclined to think that preloading the library I change the library arrangement in memory; this could hide/show some wrong memory access.

Any idea how debug this ?

G.Baroncelli

Message #35 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Goffredo Baroncelli <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: Minimal test case

Date: Wed, 16 Mar 2016 23:19:24 +0100

Ok, I was able to track down a __very__ minimal test case: the problem seems to be a "strange" interaction between the linker flag used during the creation of libutemper, and the inclusion of -lpthread[*] during the linking of mosh-server.
It is not a problem related to mosh and/or libutempter. In fact I was able to create a test without involving these two.

$ cat boom.c
extern void dofork();

int main() {
    dofork();
}

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

void dofork() {
	fork();
}

$ gcc -shared -Wl,-z,now -o libdofork.so dofork.o
$ gcc -o boom boom.c -lpthread -L$(pwd) -ldofork
$ LD_LIBRARY_PATH=$(pwd) ldd ./boom	linux-vdso.so.1 (0x00007ffe817dc000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f16b38ed000)
	libdofork.so => /home/ghigo/mosh/libdofork.so (0x00007f16b36ec000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f16b3347000)
	/lib64/ld-linux-x86-64.so.2 (0x0000562eba12a000)
$ LD_LIBRARY_PATH=$(pwd) ./boom
Segmentation fault

The key points are:
- put a fork in a shared library
- link the shared library with "-Wl,-z,now"
- compile a program with libpthread and the library above (note: libpthread is not needed)
- put libpthread before the library above

Then I got a crash. The test was performed on a debian machine with libc6 2.22. Even on a fedora F23 (=libc-2.22) I got the crash.

If I performed the same test on a debian machine with libc6 2.19 instead of libc6 2.22, the crash doesn't happen.
If I remove "-lpthread" or "-Wl,-z,now" flag, the crash doesn't happen.
If I put the fork() in the main(), the crash doesn't happen.

My (limitated) knowledge doesn't suggest me any valid reason about why the crashes. However 
- if I remove "-Wl,-z,now" from libutempter mosh-server doesn't crash.
- if I remove -lpthread from the linking of "mosh-server", mosh doesn't crash anymore. Pay attention that -lpthread is not needed, because the -pthread flag is sufficient.

BR
G.Baroncelli


[*] BTW -lpthread was required by libprotobuf

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Message #40 received at 817929@bugs.debian.org (full text, mbox, reply):

From: john hood <cgull@glup.org>

To: 817929@bugs.debian.org

Subject: Re: Minimal test case

Date: Thu, 17 Mar 2016 19:13:51 -0400

Thanks for the clues here.

I'm working on the issue from the Mosh side, see:

https://github.com/mobile-shell/mosh/issues/727

Message #47 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Matthew Gabeler-Lee <cheetah@fastcat.org>

To: Debian Bug Tracking System <817929@bugs.debian.org>

Subject: Re: mosh fails to connect, giving a UDP error

Date: Mon, 21 Mar 2016 19:23:54 -0400

Package: mosh
Version: 1.2.5-1.1
Followup-For: Bug #817929

Looks like upstream has a patch for this:

https://github.com/mobile-shell/mosh/pull/732/commits/a47917b97606a03f6bbf0cafd1fcd495b0229790

Though it looks like that's a hack and they really want this fixed in
protobuf:

https://github.com/google/protobuf/pull/1333

Which also has a patch.

This bug maybe should be moved to be against the protobuf package since that
seems the cleaner place to fix this?

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mosh depends on:
ii  dpkg            1.18.4
ii  libc6           2.22-3
ii  libgcc1         1:5.3.1-11
ii  libprotobuf9v5  2.6.1-1.3
ii  libssl1.0.2     1.0.2g-1
ii  libstdc++6      5.3.1-11
ii  libtinfo5       6.0+20160213-1
ii  libutempter0    1.1.6-3
ii  openssh-client  1:7.2p2-1
ii  zlib1g          1:1.2.8.dfsg-2+b1

Versions of packages mosh recommends:
ii  libio-socket-ip-perl              0.37-1
ii  perl-base [libio-socket-ip-perl]  5.22.1-9

mosh suggests no packages.

-- no debconf information

Message #52 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Goffredo Baroncelli <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: Re: mosh fails to connect, giving a UDP error

Date: Tue, 22 Mar 2016 23:21:31 +0100

On Mon, 21 Mar 2016 19:23:54 -0400 Matthew Gabeler-Lee <cheetah@fastcat.org> wrote:
> Package: mosh
> Version: 1.2.5-1.1
> Followup-For: Bug #817929
> 
> Looks like upstream has a patch for this:
> 
> https://github.com/mobile-shell/mosh/pull/732/commits/a47917b97606a03f6bbf0cafd1fcd495b0229790
> 
> Though it looks like that's a hack and they really want this fixed in
> protobuf:
> 
> https://github.com/google/protobuf/pull/1333
> 
> Which also has a patch.

Please give a look to

	https://sourceware.org/ml/libc-help/2016-03/msg00010.html

to me it seems that the real problem is in glibc.


BR 
G.Baroncelli
-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Message #57 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Matthew Gabeler-Lee <cheetah@fastcat.org>

To: 817929@bugs.debian.org

Subject: Re: mosh fails to connect, giving a UDP error

Date: Tue, 22 Mar 2016 21:48:43 -0400

On Tue, 22 Mar 2016 23:21:31 +0100 Goffredo Baroncelli
<kreijack@inwind.it> wrote:
> Please give a look to
>
> https://sourceware.org/ml/libc-help/2016-03/msg00010.html
>
> to me it seems that the real problem is in glibc.

From reading that thread and looking at the referenced git commit, I'm
not convinced it's a glibc bug.  While I'm definitely not an expert in
this area, it looks to me like glibc removed some legacy cruft that
should no longer have been needed by any app that used the correct
compile/link flags for pthreads.  They also added a workaround for a
common case of incorrect flags.

But what we have here is an uncommon case driven by mosh's linker
options, which means that the glibc workaround for protobuf's incorrect
linker options doesn't (can't?) work.

If protobuf didn't recommend incorrect linker options, we wouldn't have
this problem.  Seems thus this bug should be moved to the protobuf
package and the upstream patch applied?

Having mosh conflict with the broken protobuf versions would be handy
too, but may not be necessary?

Message #62 received at 817929@bugs.debian.org (full text, mbox, reply):

From: "kreijack@inwind.it" <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: Re: mosh fails to connect, giving a UDP error

Date: Wed, 23 Mar 2016 13:25:06 +0100 (CET)

On Tue, 22 Mar 2016 21:48:43 -0400 Matthew Gabeler-Lee <cheetah@fastcat.org> 
wrote:
[...]
> But what we have here is an uncommon case driven by mosh's linker
> options, which means that the glibc workaround for protobuf's incorrect
> linker options doesn't (can't?) work.

Why are you stating that passing "-lpthread" is an "Incorrect option" ?
I read somewhere that this option is _deprecated_. But I was unable to find 
any 
"official" reference.

On the best of my knowledge, it should be not incorrect linking 
an executable to an un-needed library. Inefficient, but not incorrect. And in 
any 
case it should lead to an error at compile time, not a crash in run-time.

Of course, I agree we should correct libprotobuffer to avoid suggesting to use
 an un-needed library.

Message #67 received at 817929@bugs.debian.org (full text, mbox, reply):

From: "kreijack@inwind.it" <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: Re: mosh fails to connect, giving a UDP error

Date: Wed, 23 Mar 2016 13:27:45 +0100 (CET)

On Tue, 22 Mar 2016 21:48:43 -0400 Matthew Gabeler-Lee <cheetah@fastcat.org> 
wrote:
[...]
> But what we have here is an uncommon case driven by mosh's linker
> options, which means that the glibc workaround for protobuf's incorrect
> linker options doesn't (can't?) work.

Why are you stating that passing "-lpthread" is an "Incorrect option" ?
I read somewhere that this option is _deprecated_. But I was unable to find 
any 
"official" reference. Moreover if it was legal in the past, it can be 
incorrect now.

On the best of my knowledge, it should be not incorrect linking 
an executable to an un-needed library. Inefficient, but not incorrect. And in 
any 
case it should lead to an error at compile time, not a crash in run-time.

Of course, I agree we should correct libprotobuffer to avoid suggesting to use
 an un-needed library.


BR
G.Baroncelli

Message #72 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Goffredo Baroncelli <kreijack@inwind.it>

To: 817929@bugs.debian.org

Subject: Bug in glibc

Date: Wed, 23 Mar 2016 18:50:47 +0100

According to Florian Weimer [1] I filed a bug against glibc:

https://sourceware.org/bugzilla/show_bug.cgi?id=19861


[1] https://sourceware.org/ml/libc-help/2016-03/msg00012.html

BR
G.Baroncelli

-- 
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D  17B2 0EDA 9B37 8B82 E0B5

Message #77 received at 817929@bugs.debian.org (full text, mbox, reply):

From: john hood <cgull@glup.org>

To: Matthew Gabeler-Lee <cheetah@fastcat.org>, 817929@bugs.debian.org

Subject: Re: Bug#817929: mosh fails to connect, giving a UDP error

Date: Thu, 24 Mar 2016 00:31:56 -0400

On 3/22/16 9:48 PM, Matthew Gabeler-Lee wrote:
> On Tue, 22 Mar 2016 23:21:31 +0100 Goffredo Baroncelli
> <kreijack@inwind.it> wrote:
>> Please give a look to
>>
>> https://sourceware.org/ml/libc-help/2016-03/msg00010.html
>>
>> to me it seems that the real problem is in glibc.
> 
> From reading that thread and looking at the referenced git commit, I'm
> not convinced it's a glibc bug.  While I'm definitely not an expert in
> this area, it looks to me like glibc removed some legacy cruft that
> should no longer have been needed by any app that used the correct
> compile/link flags for pthreads.  They also added a workaround for a
> common case of incorrect flags.

I haven't been able to chase these glibc details down.  Do you have
pointers to specifics for this?

> But what we have here is an uncommon case driven by mosh's linker
> options, which means that the glibc workaround for protobuf's incorrect
> linker options doesn't (can't?) work.

I agree that this issue seems to be provoked by a *change* in glibc, but
not a *bug*-- I believe the bug is protobuf's bad linker options.  All
this stuff is ill-documented though.

> If protobuf didn't recommend incorrect linker options, we wouldn't have
> this problem.  Seems thus this bug should be moved to the protobuf
> package and the upstream patch applied?

That seems reasonable to me.

> Having mosh conflict with the broken protobuf versions would be handy
> too, but may not be necessary?

I think it's not necessary; I think we'll have to fix this in packaging
for mosh-1.2.5 on unstable, and in the upstream for mosh master.  We're
working on #1 now.  I just pushed the fix for #2.

regards,

  --jh

Message #82 received at 817929-close@bugs.debian.org (full text, mbox, reply):

From: Keith Winstein <keithw@mit.edu>

To: 817929-close@bugs.debian.org

Subject: Bug#817929: fixed in mosh 1.2.5-2

Date: Thu, 24 Mar 2016 06:19:21 +0000

Source: mosh
Source-Version: 1.2.5-2

We believe that the bug you reported is fixed in the latest version of
mosh, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 817929@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Keith Winstein <keithw@mit.edu> (supplier of updated mosh package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 23 Mar 2016 22:05:34 -0700
Source: mosh
Binary: mosh
Architecture: source
Version: 1.2.5-2
Distribution: unstable
Urgency: medium
Maintainer: Keith Winstein <keithw@mit.edu>
Changed-By: Keith Winstein <keithw@mit.edu>
Description:
 mosh       - Mobile shell that supports roaming and intelligent local echo
Closes: 817929
Changes:
 mosh (1.2.5-2) unstable; urgency=medium
 .
   * debian/rules: Work around protobuf/glibc build problem
     causing mosh-server segfault. (Closes: #817929) (John Hood)
Checksums-Sha1:
 84ab2ca9d6018fdcb68c1015d7e09fd2c5617af9 1882 mosh_1.2.5-2.dsc
 5f8317b952a57be3c27def8b0015c5580ece0758 9216 mosh_1.2.5-2.debian.tar.xz
Checksums-Sha256:
 cf91c0d7548bfcc430631ff4cb8ed3687c66dfaff5009ac784699e8cdb4e8b4b 1882 mosh_1.2.5-2.dsc
 db3550752035551b795c23e607d2c9b50e8f916bdc3992202ee39f38e65e05a2 9216 mosh_1.2.5-2.debian.tar.xz
Files:
 51707f225537a4b6c8d5a1adc9e66418 1882 net optional mosh_1.2.5-2.dsc
 c61c13c34c04b4aa15db716bc9401b52 9216 net optional mosh_1.2.5-2.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW84IwAAoJECC3KDr+JUxpMLkP/R8bp3Kp1WkqOlOhlcdWM7QV
9//560LNd0ACjYE2vYnb4gcCyZydKKbXVqMughpMY3bW4q1JVQSGmedHl9gXPK6s
xMJpxa+Hq/CWCFONYvjoC4QniV44DlEX6KrdSP1yo0ZgR+X7PsnvDaiJdf3RUz/L
Bu9z48j/JiFXi1B7ifH6iXgr6tvRudaEGC484GYiQvkyRupIzxmFFGjIfVBe+HOO
C7M2hLYwKewF8w15IItE/++nv5ipLQxEczfCQfpJZqHw5qp3nuPmKaSHCs/ex103
0adOQwsnEB6BLU0h5EyxS75z2ZL5UNJsUztQ8ylPxTmyBlvO3f1J8lgDks6UmUBH
VMq1pRH5ez3O0fok8PW0nVXBB6yMvHs/rMlLiuQ1Ri4aNVZzWs5f2pInYn+DJ+UZ
bWwyI6QAGuO0AvDNR2PsC0vLrpaAFYdRZXG3DvpklkE5ANQkBbO20icP6HiAZS2j
Y2M4vpIR0sxkiODqB0wW/u33VgzqWJK9vmx79KqKHT4XWcXAcpQEvqJsqtaZeYGm
wxGZC8X1Dl7eQQMtFTq1ijZDFaRCNS2NkoTcboBcmCnWlNgxtIAAGMcPial29dyq
L3D59je2n4HRyFddogkhLub/qgucEeqx0PjsYv26bDK3kOxkhHgy9aroZ7y/vgT8
6afJOjA4kCfzdEjNwird
=1Sgy
-----END PGP SIGNATURE-----

Message #87 received at 817929@bugs.debian.org (full text, mbox, reply):

From: Matthew Gabeler-Lee <cheetah@fastcat.org>

To: john hood <cgull@glup.org>, 817929@bugs.debian.org

Subject: Re: Bug#817929: mosh fails to connect, giving a UDP error

Date: Fri, 25 Mar 2016 10:39:13 -0400

On 03/24/2016 12:31 AM, john hood wrote:
> I haven't been able to chase these glibc details down.  Do you have
> pointers to specifics for this?
My assessment was based just on reading the referenced glibc-help
thread, and the commit it referenced --
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=beff1d132c16aedd87a3f1bc7b572c8e69819015

The commit contains this comment ahead of the "trampoline" generation:

/* libpthread once had its own fork, though there was no apparent reason
   for it.  There is no use in having a separate symbol in libpthread, but
   the historical ABI requires it.  For static linking, there is no need to
   provide anything here--the libc version will be linked in.  For shared
   library ABI compatibility, there must be __fork and fork symbols in
   libpthread.so; so we define them using IFUNC to redirect to the libc
   function.  */

There is also some further discussion on the glibc thread since it was
first referenced here.  To summarize some key items from that:

"this is a bug.  Could you report it in Bugzilla here, please?"

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

https://sourceware.org/bugzilla/show_bug.cgi?id=19861

So it looks like, contrary to my assessment (I said I wasn't an expert
:), this *is* a glibc bug.  But the mosh workaround is probably still
necessary in the short term.

Send a report that this bug log contains spam.