Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing
Hi, it seems to be gcc bug. For inexplicable reason compiler optimized 'if (cp *cp)' to just 'if (*cp)' :-( Changing 'char *cp' to 'char * volatile cp' at line 468 in support/export/client.c is enough to explain to gcc that it has no idea what it is doing, and fixes the crash. I think that after code does 'strncpy(new, old, cp-old)' or 'new[cp-old] = 0' or 'if (cp != old *cp)' compiler believes 'cp' cannot be NULL, forgetting that both 'cp' and 'old' could have been NULL, making these expressions valid for NULL cp. Petr nfsworkaround.patch Description: Binary data
Bug#757835: nfs-kernel-server: after update 1.2.8-6-1.2.8-8 rpc.mountd starts crashing
amd64. I think it affects all architectures. In case you want to
follow-up, attached is minimum testcase I could come up with. It
crashes with gcc-4.9 and -O2. No crash with gcc-4.8, or at -O1.
$gcc-4.9 -W -Wall -O2 client.c ./a.out
Segmentation fault
$gcc-4.8 -W -Wall -O2 client.c ./a.out
$gcc-4.9 -W -Wall -O1 client.c ./a.out
$
Petr
On Mon, Aug 11, 2014 at 12:15 PM, Steve Langasek vor...@debian.org wrote:
On Mon, Aug 11, 2014 at 11:49:16AM -0700, Petr Vandrovec wrote:
Hi,
it seems to be gcc bug. For inexplicable reason compiler optimized
'if (cp *cp)' to just 'if (*cp)' :-(
Changing 'char *cp' to 'char * volatile cp' at line 468 in
support/export/client.c is enough to explain to gcc that it has no
idea what it is doing, and fixes the crash.
I think that after code does 'strncpy(new, old, cp-old)' or
'new[cp-old] = 0' or 'if (cp != old *cp)' compiler believes 'cp'
cannot be NULL, forgetting that both 'cp' and 'old' could have been
NULL, making these expressions valid for NULL cp.
Are you seeing this problem on i386 (like the original submitter), or do you
see this problem on a different architecture?
(If it's a compiler problem, this will be relevant to getting it fixed
properly.)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
char buf[100];
void
add_name(char *old)
{
char *cp = old;
while (cp *cp) {
cp++;
}
__builtin_strncpy(buf, old, cp-old);
if (cp != old) {
buf[0] = 'Q';
}
if (cp *cp) {
buf[0] = 'Q';
}
}
int main(void) {
add_name(0);
return 0;
}
Bug#519774: libc6: causes many programs not to be able to resolve dns addresses
Hello,
it seems that DNS resolver is grossly confused, and sends
two DNS requests on same socket back to back (strace below is
from 'lynx http://www.jeep.com'). In first one DNS server
responded only to second packet sent by resolver, and resolve
failed (after that mdns was tried, and eventually lynx reported
error that www.jeep.com does not exist). In second one DNS
server responded only to first packet (in my tests I've never
seen DNS server responding to both requests), and although DNS
resolver still uselessly waited for 5 seconds, slowing web browsing
to being almost unusable, after that 5 seconds DNS resolver
declared success, and moved on.
My /etc/resolv.conf is:
gwy:~# cat /etc/resolv.conf
domain hsd1.ca.comcast.net.
search hsd1.ca.comcast.net.
nameserver 68.87.76.178
nameserver 68.87.78.130
nameserver 68.87.69.146
gwy:~#
It seems to be caused by __libc_res_nquery always sending both
T_A and T_ request when T_UNSPEC query is being sent, and
getting confused when only T_ reply arrives.
2008-05-10 Ulrich Drepper drep...@redhat.com
...
* resolv/res_query.c (__libc_res_nquery): Take two additional
parameters for second answer buffer. Handle
type=T_UNSPEC to mean look up IPv4 and IPv6.
Change all callers.
Sending only one reply seems to be property of Comcast's servers.
When I use DNS server 147.32.1.20 (which runs bind), I'm getting two
responses. I'll try talking to Comcast support, but I doubt they'll
have any idea what I'm talking about.
Petr
16469 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
16469 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, 28) = 0
16469 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
16469 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
16469 gettimeofday({1237095720, 803573}, NULL) = 0
16469 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3,
revents=POLLOUT}])
16469 send(3, \30\223\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\1\0\1,
30, MSG_NOSIGNAL) = 30
16469 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3,
revents=POLLOUT}])
16469 send(3, \3503\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\34\0\1,
30, MSG_NOSIGNAL) = 30
16469 gettimeofday({1237095720, 803994}, NULL) = 0
16469 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3,
revents=POLLIN}])
16469 ioctl(3, FIONREAD, [159]) = 0
16469 recvfrom(3,
\3503\201\200\0\1\0\2\0\1\0\0\3www\4jeep\3com\0\0\34\0\1\300\f...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, [16]) = 159
16469 gettimeofday({1237095720, 831053}, NULL) = 0
16469 poll([{fd=3, events=POLLIN}], 1, 4972) = 0 (Timeout)
16469 close(3) = 0
17497 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 3
17497 connect(3, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, 28) = 0
17497 fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
17497 fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
17497 gettimeofday({1237096105, 330041}, NULL) = 0
17497 poll([{fd=3, events=POLLOUT}], 1, 0) = 1 ([{fd=3,
revents=POLLOUT}])
17497 send(3, 1\311\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\1\0\1, 30,
MSG_NOSIGNAL) = 30
17497 poll([{fd=3, events=POLLIN|POLLOUT}], 1, 5000) = 1 ([{fd=3,
revents=POLLOUT}])
17497 send(3, \367\241\1\0\0\1\0\0\0\0\0\0\3www\4jeep\3com\0\0\34\0\1,
30, MSG_NOSIGNAL) = 30
17497 gettimeofday({1237096105, 330529}, NULL) = 0
17497 poll([{fd=3, events=POLLIN}], 1, 4999) = 1 ([{fd=3,
revents=POLLIN}])
17497 ioctl(3, FIONREAD, [117]) = 0
17497 recvfrom(3,
1\311\201\200\0\1\0\3\0\0\0\0\3www\4jeep\3com\0\0\1\0\1\300\f...,
2048, 0, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr(68.87.76.178)}, [16]) = 117
17497 gettimeofday({1237096105, 350551}, NULL) = 0
17497 poll([{fd=3, events=POLLIN}], 1, 4979) = 0 (Timeout)
17497 close(3) = 0
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515229: New dash has serious problems with waiting for spawned processes
Package: dash Version: 0.5.5.1-1 Severity: critical Hello, new dash has some serious problems with waiting on spawned processes, which completely breaks apt-move - at the end apt-move spawns pipe as shown below: p...@gwy:~$ cat /tmp/err 20768 tty4 S+ 0:00 \_ dash /usr/bin/apt-move sync 21840 tty4 S+ 0:00 \_ sort 21841 tty4 S+ 0:00 \_ awk -f /usr/share/apt-move/cmpbignum.awk -f /usr/share/apt-move/cmpversion.awk -f /usr/share/apt-move/getdist.awk -f /usr/share/apt-move/get2 21843 tty4 S+ 0:00 \_ sort 21844 tty4 D+ 0:00 \_ /usr/bin/awk -f /usr/share/apt-move/pkg1 /tmp/MOVE_lfwAkG/make_pkg_files-fifo1 /tmp/MOVE_lfwAkG/make_pkg_files-contents/unstable/main/binary-i386 21845 tty4 S+ 0:00 \_ gzip 21846 tty4 S+ 0:00 \_ tee dists/unstable/main/binary-i386/Packages /tmp/MOVE_lfwAkG/make_pkg_files-fifogz Once 'tee' completes, it starts consuming 100% CPU, and can be killed only by -9... p...@gwy:~$ cat /tmp/err2 20768 tty4 R+ 0:02 \_ dash /usr/bin/apt-move sync And strace shows that it is doing endless stream of calls to wait4(), waiting for someone who does not exist anymore: p...@gwy:~$ head -10 /tmp/err3 wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) wait4(-1, 0xffd236e8, 0, NULL) = -1 ECHILD (No child processes) p...@gwy:~$ I suspect that it could be same as bug 515064, but maybe not. In any case, as far as I can tell, severity should be critical as it breaks unrelated package (apt-move). Downgrading back to 0.5.4 fixes the problem. Thanks, Petr -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#429619: openssh-server: password based authentication not working following upgrade
Hello, it is still not quite right. To work around 4.6p1-1 bug I enabled 'PasswordAuthenticaion yes' in sshd config file, and it worked great. But for 4.6p1-2 I'm prompted for password, and then thing crashes (Works fine with key based authentication): petr-dev3:/var/log# ssh localhost -l petr Password: Read from remote host localhost: Connection reset by peer Connection to localhost closed. petr-dev3:/var/log# tail auth.log Jun 21 17:50:28 petr-dev3 sshd[5445]: fatal: PAM: pam_setcred(): Permission denied Jun 21 17:50:41 petr-dev3 login[5411]: (pam_unix) session opened for user root by (uid=0) Jun 21 17:50:41 petr-dev3 login[5448]: ROOT LOGIN on 'tty1' Jun 21 17:56:21 petr-dev3 login[5412]: (pam_unix) session opened for user root by (uid=0) Jun 21 17:56:21 petr-dev3 login[5490]: ROOT LOGIN on 'tty2' Jun 21 17:56:56 petr-dev3 sshd[5496]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost.localdomain user=petr Jun 21 17:57:00 petr-dev3 sshd[5496]: Accepted keyboard-interactive/pam for petr from 127.0.0.1 port 53393 ssh2 Jun 21 17:57:00 petr-dev3 sshd[5499]: (pam_unix) session opened for user petr by (uid=0) Jun 21 17:57:00 petr-dev3 sshd[5499]: fatal: PAM: pam_setcred(): Permission denied Jun 21 17:57:00 petr-dev3 sshd[5499]: (pam_unix) session closed for user petr petr-dev3:/var/log# After I put 'PasswordAuthentication no' back into sshd config file, things look better... (though I do not understand how PAM can work without PasswordAuthentication, as server definitely needs my cleartext password to be able to send it to PAM...) Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428937: ncpfs: FTBFS: ncpm_common.c:1229: error: expected expression before 'struct'
Lucas Nussbaum wrote: During a rebuild of all packages in sid, your package failed to build on i386. Fix below should fix problem. Probably time to release ncpfs-2.2.7, it looks really bad that there is 2000+ warnings in the build. Petr ncpm_common.c: In function 'process_connection': ncpm_common.c:1229: error: expected expression before 'struct' make[2]: *** [ncpm_common.o] Error 1 diff -urN sutil.x/ncpm_common.c sutil/ncpm_common.c --- sutil.x/ncpm_common.c 2007-06-15 01:14:28.0 -0700 +++ sutil/ncpm_common.c 2007-06-15 01:12:30.0 -0700 @@ -85,6 +85,7 @@ #include stdio.h #include string.h #include signal.h +#include stddef.h #include pwd.h #include grp.h #include ncp/ext/socket.h diff -urN sutil.x/ncpm_common.c sutil/ncpm_common.c --- sutil.x/ncpm_common.c 2007-06-15 01:14:28.0 -0700 +++ sutil/ncpm_common.c 2007-06-15 01:12:30.0 -0700 @@ -85,6 +85,7 @@ #include stdio.h #include string.h #include signal.h +#include stddef.h #include pwd.h #include grp.h #include ncp/ext/socket.h
Bug#375300: new tar behavior and --wildcards
[I'm not on Debian-devel, so please CC me] Bdale Garbee wrote: The new tar behavior with respect to wildcards is not a change I introduced just for Debian, it's a new upstream change that appears to be quite intentional and well documented, as per this text from the tar info docs: The following table summarizes pattern-matching default values: MembersDefault settings -- Inclusion `--no-wildcards --anchored --no-wildcards-match-slash' Exclusion `--wildcards --no-anchored --wildcards-match-slash' -- Footnotes -- (1) Notice that earlier GNU `tar' versions used globbing for inclusion members, which contradicted to UNIX98 specification and was not documented. Although maybe that it was not documented, it was widely used, and it exists for at least 6 years. So upstream should fix documentation instead of tar behavior. As documentation is not part of Debian, it does not matter for Debian anyway. Obviously, the problems reported with various Debian utilities are due to the default now being --no-wildcards for inclusion combined with a dependency on the footnoted feature of previous versions of GNU tar. Since this seems to have been an intentional behavior change by upstream to better align with a published standard, I'm uninclined to fight it, and think our best response is to update our utilities to include the --wildcards option, with a suitable versioned dependency on tar. This decision makes tar completely incompatible. Programs which worked fine with tar for 6 years are suddenly broken, and now you have to have two versions - one for 'tar' before this brokeness, which do not pass --wildcards, and one for this broken 'tar', which passes --wildcards. And older version on newer 'tar' extracts nothing, while new version on older 'tar' fails with an unknown option error. Maybe it could be default for tar's POSIX mode, but I have no idea why GNU mode behavior should be changed in any way. Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375300: tar 1.15.91 breaks at least apt-listchanges
Package: tar Version: 1.15.91-1 Severity: critical Justification: makes apt-listchanges unusable When apt-listchanges tries to extract changelogs, it hits new feature of tar 1.15.91 which forbids wildcards in filenames, and so it fails to do anything as it finds no changelog: 12528 execve(/bin/sh, [sh, -c, dpkg-deb --fsys-tarfile /var/cache/apt/archives/ttf-dejavu_2.7-2_all.deb |tar xf - -C /tmp/apt-listchangesEKaRJr \'usr/doc/*/NEWS.Debian.gz\' \'usr/share/doc/*/NEWS.Debian.gz\' \'usr/doc/*/NEWS.Debian\' \'usr/share/doc/*/NEWS.Debian\' \'./usr/doc/*/NEWS.Debian.gz\' \'./usr/share/doc/*/NEWS.Debian.gz\' \'./usr/doc/*/NEWS.Debian\' \'./usr/share/doc/*/NEWS.Debian\' \'usr/doc/*/changelog.Debian.gz\' \'usr/share/doc/*/changelog.Debian.gz\' \'usr/doc/*/changelog.Debian\' \'usr/share/doc/*/changelog.Debian\' \'./usr/doc/*/changelog.Debian.gz\' \'./usr/share/doc/*/changelog.Debian.gz\' \'./usr/doc/*/changelog.Debian\' \'./usr/share/doc/*/changelog.Debian\' \'usr/doc/*/changelog.gz\' \'usr/share/doc/*/changelog.gz\' \'usr/doc/*/changelog\' \'usr/share/doc/*/changelog\' \'./usr/doc/*/changelog.gz\' \'./usr/share/doc/*/changelog.gz\' \'./usr/doc/*/changelog\' \'./usr/share/doc/*/changelog\' 2/dev/null], [SHELL=/bin/bash, TERM=linux, HUSHLOGIN=FALSE, USER=root, MAIL=/var/mail/root, PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin:., PWD=/tmp, LANG=C, PS1=\\h:\\w\\$ , SHLVL=1, HOME=/root, LOGNAME=root, LC_CTYPE=cs_CZ, _=/usr/bin/strace, OLDPWD=/tmp/w]) = 0 12530 write(2, tar: , 5) = 5 12530 write(2, usr/doc/*/NEWS.Debian.gz: Not found in archive, 46) = 46 12530 write(2, \n, 1) = 1 12530 write(2, tar: , 5) = 5 12530 write(2, usr/share/doc/*/NEWS.Debian.gz: Not found in archive, 52) = 52 12530 write(2, \n, 1) = 1 12530 write(2, tar: , 5) = 5 12530 write(2, usr/doc/*/NEWS.Debian: Not found in archive, 43) = 43 12530 write(2, \n, 1) = 1 12530 write(2, tar: , 5) = 5 12530 write(2, usr/share/doc/*/NEWS.Debian: Not found in archive, 49) = 49 12530 write(2, \n, 1) = 1 ... Please, if you must introduce some new options, make '--wildcards' default so you do not change behavior in backward incompatible way. Or, if you are absolutely sure that no other program on the world besides apt-listchanges depends on this behavior, feel free to reassign this to apt-listchanges. But I'm absolutely sure that apt-listchanges is not only program which depends on this behavior (as I've written couple of tools which depend on this as well)... Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341234: New dash 0.5.3-1 breaks apt-move
Package: apt-move
Version: 4.2.24-1
Severity: grave
Tags: patch
Hello,
apt-move uses
if ! type exp /dev/null 21; then
if type dash /dev/null 21; then
exec dash $0 $@
else
exec ash $0 $@
fi
fi
to make sure that it is executing under dash or ash. dash 0.5.3-1 breaks
this code, causing it to enter endless loop as dash lost its 'exp' builtin:
$ dpkg -l dash
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version
Description
+++---
ii dash 0.5.2-8
The Debian Almquist Shell
$ type exp
exp is a shell builtin
$ dpkg -l dash
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version
Description
+++---
ii dash 0.5.3-1
The Debian Almquist Shell
$ type exp
exp: not found
It is probably caused by this upstream change:
2005-02-28 Herbert Xu [EMAIL PROTECTED]
* Replaced EXEVAL with SKIPEVAL.
* Update funcnest atomically.
* Only set skipcount for break and continue.
* Removed expcmd built-in.
* Normalise input in likely/unlikely macros.
I've verified that upstream apt-move 4.2.25 still uses this detection.
If you believe that this detection is correct and dash is package with problem,
then feel free to reassign this to dash. As Herbert is upstream maintainer
for both dash and apt-move, it probably does not matter a lot, as it
ends up in his mailbox this way or another.
For Debian I would apply patch below, which removes dash/ash detection and
forces dash through #!.
Thanks,
Petr Vandrovec
diff -urN apt-move-4.2.24/apt-move apt-move-4.2.24/apt-move
--- apt-move-4.2.24/apt-move2005-10-24 17:35:09.0 +0200
+++ apt-move-4.2.24/apt-move2005-11-29 13:42:54.0 +0100
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/dash
#
# Copyright (c) 1999 Michael Merten [EMAIL PROTECTED]
# Copyright (c) 1999-2000 Gregory T. Norris [EMAIL PROTECTED]
@@ -18,14 +18,6 @@
#
set -e
-if ! type exp /dev/null 21; then
- if type dash /dev/null 21; then
- exec dash $0 $@
- else
- exec ash $0 $@
- fi
-fi
-
[ ${CDPATH+1} ] unset CDPATH
if [ ${LC_ALL+1} ]; then
export LC_MONETARY=$LC_ALL
diff -urN apt-move-4.2.24.go/debian/control apt-move-4.2.24/debian/control
--- apt-move-4.2.24.go/debian/control 2005-10-21 03:18:29.0 +0200
+++ apt-move-4.2.24/debian/control 2005-11-29 13:42:40.0 +0100
@@ -7,7 +7,7 @@
Package: apt-move
Architecture: any
-Depends: bc, dash | ash, ${shlibs:Depends}
+Depends: bc, dash, ${shlibs:Depends}
Recommends: apt
Description: Maintain Debian packages in a package pool
apt-move is used to move a collection of Debian package files into a proper
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339136: Changes in stat package output break apt-move
Package: coreutils Version: 5.93-2 Severity: critical Justification: renders apt-move unusable Hello, in the past 'stat -L -c %s / /' produced 4096 LF 4096 LF while now (since 5.93 update) it produces 40964096 without any explanation why this happened. This breaks at least apt-move and some programs I've written. But what's worse is that now stat does not provide any way how to get each of stat results on separate line - %s\n just generates 4096\n4096\n, without interpreting \n... Can you revert to the old behavior and provide special option for new (IMHO broken) one, or provide some method how to embed LF to the output without actually having LF embedded directly into shell scripts? Though I would prefer backward compatibility over even bigger incompatibility. See bug 339024 for apt-move's half of story. Thanks, Petr Vandrovec -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328568: ssh 4.2p1-3 crash
Hello, due to pure luck (new ssh crashed on all my systems except one) I've found workaround - default_realm in [libdefaults] in /etc/krb5.conf must not be empty. default_realm = crashes, default_realm = x works... Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
