Bug#803941: Reproducing " samba: cp and cat return an endless stream of 0s when reading a file on a samba share"
This looks to be fixed :) Server running Debian Stretch with Samba 2:4.5.16+dfsg-1 and client running Debian Stretch with cifs-utils 2:6.7-1: [N] ian@draal~> mount /mnt/nas [I] ian@draal~> cd /mnt/nas/ [I] ian@draal/m/nas> echo foo > bar [I] ian@draal/m/nas> cat bar | hexdump -Cv 66 6f 6f 0a |foo.| 0004 Cheers, -Ian
Bug#803941: Debian bug #803941
Thanks Dennis. Forwarding this to the bug report since it might be useful to others and may help narrow down the cause. Unfortunately this workaround did not work for me - I didn't have oplocks in the smb.conf to begin with (and I tried adding it and related options to no avail) :( On 17 November 2015 at 12:11, Dennis Linnell wrote: > Regarding your Debian bug report #803941, "samba: cp and cat return an > endless stream of 0s when reading a file on a samba share", I > encountered the same symptom. After I removed "oplocks = no" from > smb.conf (thereby taking the default of oplocks = yes) and restarted > smbd on the server, the symptom disappeared. Consider trying that if it > is applicable to your configuration. > > Thanks for reporting the bug. Your report was helpful to me. > > Best regards, > Dennis
Bug#803941: samba: cp and cat return an endless stream of 0s when reading a file on a samba share
Package: samba
Version: 2:4.1.20+dfsg-1
Severity: important
Dear Maintainer,
* What led up to the situation?
Recently I noticed that trying to copy or otherwise manipulate files on
my nas box running Debian Stable would seemingly hang in some
circumstances, such as when using cp or cat, but not when using rsync or
directly running hexdump on a file.
Examining the destination file when using cp showed that it was in fact
growing endlessly, even if the source file was only a few bytes.
Running cat on any file on the samba mount would also seemingly hang,
and piping the output through hexdump showed it was spewing 0s (using
hexdump directly will not see this problem as it only reads the expected
filesize reported by stat())
* What exactly did you do (or not do) that was effective (or
ineffective)?
1. Create a samba share on a Debian system
2. Mount that share on another system
3. On the client, cd into the mounted share and run:
echo foo > bar
cat bar | hexdump -Cv
* What was the outcome of this action?
66 6f 6f 0a 00 00 00 00 00 00 00 00 00 00 00 00 |foo.|
0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
...
* What outcome did you expect instead?
66 6f 6f 0a |foo.|
0004
This seems to be a server issue, as attaching strace to smbd while
running the above command produced this:
pread(32, "foo\n", 65536, 0)= 4
writev(37,
[{"foo\n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 65536}],
1) = 65536
pread(32, "", 65536, 65536) = 0
writev(37,
[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
65536}], 1) = 65536
poll([{fd=11, events=POLLIN|POLLHUP}, {fd=7, events=POLLIN|POLLHUP}, {fd=37,
events=POLLIN|POLLHUP}], 3, 59577) = 1 ([{fd=37, revents=POLLIN}])
poll([{fd=37, events=POLLIN|POLLHUP}], 1, 0) = 1 ([{fd=37, revents=POLLIN}])
read(37, "\0\0\0;", 4) = 4
read(37,
"\377SMB.\0\0\0\0\0\1\300\0\0\0\0\0\0\0\0\0\0\0\0\303\224\0A\302\215\321\31"...,
59) = 59
writev(37,
[{"\0\2\0;\377SMB.\0\0\0\0\200\3\310\0\0\0\0\0\0\0\0\0\0\0\0\303\224\0A"...,
63}], 1) = 63
pread(32, "", 65536, 131072)= 0
writev(37,
[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
65536}], 1) = 65536
pread(32, "", 65536, 196608)= 0
writev(37,
[{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
65536}], 1) = 65536
poll([{fd=11, events=POLLIN|POLLHUP}, {fd=7, events=POLLIN|POLLHUP}, {fd=37,
events=POLLIN|POLLHUP}], 3, 59556) = 1 ([{fd=37, revents=POLLIN}])
poll([{fd=37, events=POLLIN|POLLHUP}], 1, 0) = 1 ([{fd=37, revents=POLLIN}])
read(37, "\0\0\0;", 4) = 4
...
As you can see, the pread call is behaving correctly, but the daemon
ignored the return value and appears to be using the total buffer size
instead (64K bytes are sent to the client, offset increases by 64K each
call, end of file is being ignored).
This bug is confirmed to be currently present in:
Debian stable (2:4.1.17+dfsg-2)
Debian testing (2:4.1.17+dfsg-4)
Debian unstable (2:4.1.20+dfsg-1)
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages samba depends on:
ii adduser 3.113+nmu3
ii dpkg 1.17.25
ii libasn1-8-heimdal1.6~rc2+dfsg-9
ii libbsd0 0.7.0-2
ii libc62.19-18
ii libcomerr2 1.42.12-1.1
ii libhdb9-heimdal [heimdal-hdb-api-8] 1.6~rc2+dfsg-9
ii libkdc2-heimdal 1.6~rc2+dfsg-9
ii libkrb5-26-heimdal 1.6~rc2+dfsg-9
ii libldb1 2:1.1.21-1
ii libpam-modules 1.1.8-3.1
ii libpam-runtime 1.1.8-3.1
ii libpopt0 1.16-10
ii libpython2.7 2.7.9-2
ii libroken18-heimdal 1.6~rc2+dfsg-9
ii libtalloc2 2.1.
Bug#794667:
Another way that a distro can mitigate this (and other) attacks on a user process like gpg-agent is by installing it with the setgid bit set. The Linux kernel will prevent ptrace attacks on such a process in a race free manner. for example, ssh-agent already does exactly this: ian@draal~ [i]> ls -l /usr/bin/ssh-agent -rwxr-sr-x 1 root ssh 350232 Mar 23 11:32 /usr/bin/ssh-agent* -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758515: RM: sup-mail -- RoQA; Uses obsolete ruby1.9.1, upstream vanished
> Someone needs to jump on this if the want to prevent removal. It needs to be > updated to work with ruby2.1 very soon. It sounds like upstream sup 0.19.0 already works with Ruby 2.1 - can we get that version in Debian? https://groups.google.com/forum/#!msg/supmua/lDzI7VY8Qhw/Fh6Dg4hXzE4J https://github.com/sup-heliotrope/sup/releases/tag/release-0.19.0 Cheers, -Ian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#758515: RM: sup-mail -- RoQA; Uses obsolete ruby1.9.1, upstream vanished
On Mon, 18 Aug 2014 08:39:29 -0400 Scott Kitterman wrote: > Since upstream has vanished, it appears upgrading is unlikely, so removal it > is. Or maybe upstream just had to move since Rubyforge was shut down? http://supmua.org/ https://github.com/sup-heliotrope -Ian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#724735: Regression
This is a regression! Until bluez is patched to allow both modes to be enabled simultaneousley without breaking either one, please remove the patch from Canonical titled "Enable the Gateway and Source audio profiles by default". For people who really want the less common use-case of having their computer receive audio from another bluetooth device rather than sending audio to bluetooth headphones, THEY can change the damn setting in audio.conf like they were doing before! Sorry for using harsh language, I'm pissed off at Canonical's lack of testing on this one! There's a reason I use Debian and not Ubuntu and I'm not terribly happy that they still managed to break my system. This is a quote from Ubuntu's bug report that added this patch: > > Has this been tested with an Android and an iPhone > > How much testing coverage did this get? > I don't think testing this should be a prerequisite THERE IS NO EXCUSE - TEST YOUR PATCHES!!! Instructions to fix: # apt-get build-dep bluez $ apt-get source bluez $ cd bluez-4.101/debian/patches - edit series file, remove or comment out 0008-Enable-the-Gateway-and-Source-audio-profiles-by-defa.patch $ cd ../.. $ dpkg-buildpackage -rfakeroot $ cd .. # dpkg -i *.deb I need to go cool off. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687107: zsnes: ZSNES often freezes when resuming game
Package: zsnes
Version: 1.510+bz2-4
Severity: important
Tags: upstream patch
Dear Maintainer,
After pausing a game with escape to go to the zsnes menu, zsnes often
locks up when resuming the game.
It seems that sem_GetTicks sometimes returns NAN. If this happens when
resuming the game (i.e. from Start60HZ), than the 'start' variable can
be set to NAN, which causes this test in CheckTimers to never succeed:
while ((end - start) >= update_ticks_pc).
Since this is a floating point issue, the CPU may be relevant. Mine is:
Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz
This issue has been discussed further on:
http://board.zsnes.com/phpBB3/viewtopic.php?f=3&t=2337&p=225072#p225072
And I have created a patch to fix it by replacing the floating point
arithmetic with 64bit integer arithmetic:
https://raw.github.com/DarkStarSword/junk/master/patches/zsnes-linux-resume-freeze-fix.patch
Given upstream is in the middle of a huge 5+ year re-write, It's not
clear if this will be fixed in an upstream version any time soon (as
seen in the above post, this problem has existed since at least 2005),
so I propose picking the patch up in Debian in the interim.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages zsnes depends on:
ii libao41.1.0-2
ii libc6 2.13-35
ii libgcc1 1:4.7.1-2
ii libgl1-mesa-glx [libgl1] 8.0.4-2
ii libncurses5 5.9-10
ii libpng12-01.2.49-1
ii libsdl1.2debian 1.2.15-5
ii libstdc++64.7.1-2
ii libtinfo5 5.9-10
ii zlib1g1:1.2.7.dfsg-13
zsnes recommends no packages.
zsnes suggests no packages.
>From 2c29409f6c7dd7cbacd7027b4afcc08546fa7a66 Mon Sep 17 00:00:00 2001
From: Ian Munsie
Date: Mon, 10 Sep 2012 03:51:13 +1000
Subject: [PATCH] Replace floating point arithmetic causing freeze with 64bit
integer arithmetic
It seems that sem_GetTicks sometimes returns NAN. If this happens when
resuming the game (i.e. from Start60HZ), than the start variable can be
set to NAN, which causes this test in CheckTimers to never succeed:
while ((end - start) >= update_ticks_pc)
So it never runs Game60hzcall and therefore appears to freeze.
Using gdb to change start to a real number less than end allows zsnes to
continue.
See this forum post for more details:
http://board.zsnes.com/phpBB3/viewtopic.php?f=3&t=2337&p=225071#p225071
This patch changes it to use a 64bit integer instead of floating point
arithmetic to avoid hitting these cases.
Also, remove the unused start2, end2, and update_ticks_pc2 variables.
Signed-off-by: Ian Munsie
---
src/linux/sdllink.c | 35 ---
1 file changed, 12 insertions(+), 23 deletions(-)
diff --git a/src/linux/sdllink.c b/src/linux/sdllink.c
index 4274c9d..eece048 100644
--- a/src/linux/sdllink.c
+++ b/src/linux/sdllink.c
@@ -111,23 +111,23 @@ static BYTE IsActivated = 1;
/* TIMER VARIABLES/MACROS */
// millisecond per world update
-#define UPDATE_TICKS_GAME (1000.0/59.948743718592964824120603015060)
-#define UPDATE_TICKS_GAMEPAL (20.0)
-#define UPDATE_TICKS_GUI (1000.0/36.0)
-#define UPDATE_TICKS_UDP (1000.0/60.0)
+#define UPDATE_TICKS_GAME (100.0/59.948743718592964824120603015060)
+#define UPDATE_TICKS_GAMEPAL (2)
+#define UPDATE_TICKS_GUI (100/36)
+#define UPDATE_TICKS_UDP (100/60)
int T60HZEnabled = 0;
int T36HZEnabled = 0;
-float end, end2;
-float start, start2;
-float update_ticks_pc, update_ticks_pc2;
+unsigned long long end;
+unsigned long long start;
+unsigned long long update_ticks_pc;
// Used for semaphore code
static SDL_sem *sem_frames = NULL;
static struct timeval sem_start;
void sem_sleep_rdy(void);
void sem_sleep_die(void);
-float sem_GetTicks(void);
+unsigned long long sem_GetTicks(void);
extern unsigned char romispal;
@@ -830,7 +830,6 @@ int startgame()
void Start60HZ(void)
{
- update_ticks_pc2 = UPDATE_TICKS_UDP;
if (romispal == 1)
{
update_ticks_pc = UPDATE_TICKS_GAMEPAL;
@@ -842,7 +841,6 @@ void Start60HZ(void)
// Restore timer data from semaphore data
start = sem_GetTicks();
- start2 = sem_GetTicks();
T36HZEnabled = 0;
T60HZEnabled = 1;
}
@@ -854,12 +852,10 @@ void Stop60HZ(void)
void Start36HZ(void)
{
- update_ticks_pc2 = UPDATE_TICKS_UDP;
update_ticks_pc = UPDATE_TICKS_GUI;
// Restore timer data from semaphore data
start = sem_GetTicks();
- start2 = sem_GetTicks();
T60HZEnabled = 0;
T36HZEnabled = 1;
}
@@ -1097,14 +1093,6 @@ void initwinvideo(void)
void CheckTimers(void)
{
- //QueryPerformanceCounter((LARGE_INTEGER*)&end2);
- end2 = sem_GetTicks();
-
- while
