Package: ktrace
Version: 10.0-1
Severity: normal
Control: block -1 by 736198
A consequence of this is that kdump builds are no longer deterministic.
Sometimes
kdump will build with more knowledge (e.g. mount flags, ioctl names, etc) than
other times.
On 20/01/2014 23:12, Robert Millan wrote:
found 736202 2.16-1
found 736202 2.14-3
# regression since this version
fixed 736202 2.12-2
thanks
I see the same thing in a sid chroot on a wheezy system (kfreebsd-amd64
9.0). Seems to affects grep 2.16-1 and 2.14-3, but not grep 2.12-2 from
wheezy running in the same chroot.
I found that in
This is about 100x times harder to reproduce running under ktrace but I
got lucky. The problematic syscall is right here:
egrepRET read 32768/0x8000
egrepCALL lseek(0,0,SEEK_CUR)
egrepRET lseek 32768/0x8000
egrepCALL lseek(0,0x8000,SEEK_HOLE)
-egrepRET lseek
Hi Jeff!
On 21/01/14 02:38, Jeff Epler wrote:
Could it be http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ?
I think you might be right:
From: Andriy Gapon a...@freebsd.org
On FreeBSD the ioctl(2) system call does copyin/copyout of the data argument
and
thus those extra
Could it be http://www.freebsd.org/cgi/query-pr.cgi?pr=164445 ?
It looks like that fix from reply 3 is not in kernel 9.0-10+deb70 which
is what I'm running (but I have Wheezy userspace, so I haven't
reproduced a problem either)
Jeff
--
To UNSUBSCRIBE, email to
5 matches
Mail list logo
