Message from David Roundy:

>> Doesn't like pasted text.
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333251
>
> I've seen this before, but it's hard to reproduce, and I haven't tracked
> down what precisely causes it.  It's something to do with our buffer
> handling.

I have also seen this.

peace,

  isaac

>>> Doesn't like pasted text.
>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333251

Any chance somebody could dtry to reproduce this under strace, and
find out which operation exactly is failing?

I suspect it might be a problem with the Ghc runtime, though.  Could
some Haskell guru find out if the Ghc people already know about that?

                                        Juliusz

On Mon, Dec 05, 2005 at 04:16:21AM +0000, Juliusz Chroboczek wrote:
> Any chance somebody could try to reproduce this under strace, and
> find out which operation exactly is failing?

I've reproduced it, but the strace is 28 megs, so I'm just pasting in the
very end of the strace.  I reproduced this by running darcs record -l in a
large directory (a darcs directory, actually), and pasting into the
terminal a large number of y's.  It's possible that this strace is messed
up because the file foobar on the first line is the strace output itself.

Hope this is helpful.

David

write(1, "+open(\"/tmp/foo/foobar\", O_RDONL"..., 70) = 70
write(1, "\n", 1)                       = 1
write(1, "+fcntl64(3, F_GETFL)            "..., 89) = 89
write(1, "\n", 1)                       = 1
write(1, "+fcntl64(3, F_SETFL, O_RDONLY|O_"..., 57) = 57
write(1, "\n", 1)                       = 1
write(1, "+fstat64(3, {st_mode=S_IFREG|064"..., 60) = 60
write(1, "\n", 1)                       = 1
write(1, "+fstat64(3, {st_mode=S_IFREG|064"..., 60) = 60
write(1, "\n", 1)                       = 1
write(1, "+ioctl(3, SNDCTL_TMR_TIMEBASE or"..., 97) = 97
write(1, "\n", 1)                       = 1
write(1, "+fstat64(3, \33[01;31m$\33[00m", 26) = 26
write(1, "\n", 1)                       = 1
rt_sigprocmask(SIG_BLOCK, [HUP INT ABRT PIPE TERM], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
write(1, "Shall I record this patch? (915/"..., 66) = 66
read(0, "y", 1)                         = 1
write(1, "\n", 1)                       = 1
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon echo ...}) = 0
rt_sigprocmask(SIG_BLOCK, [TTOU], [], 8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
select(1, [0], NULL, NULL, {0, 0})      = 1 (in [0], left {0, 0})
read(0, "y", 1)                         = 1
_llseek(0, -1, 0xbf98f800, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
_llseek(0, -1, 0xbf98f800, SEEK_CUR)    = -1 ESPIPE (Illegal seek)
unlink("/tmp/foo/_darcs/lock")          = 0
write(2, "darcs: ", 7darcs: )                  = 7
write(2, "<stdin>: hSetBuffering: unsuppor"..., 61<stdin>: hSetBuffering: unsupported operation (Illegal 
seek)
) = 61
write(2, "\n", 1
)                       = 1
times({tms_utime=7627, tms_stime=883, tms_cutime=0, tms_cstime=0}) = 441975594
setitimer(ITIMER_VIRTUAL, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
fcntl64(0, F_GETFL)                     = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(0, F_SETFL, O_RDWR)             = 0
fcntl64(1, F_GETFL)                     = 0x2 (flags O_RDWR)
fcntl64(2, F_GETFL)                     = 0x8001 (flags O_WRONLY|O_LARGEFILE)
rt_sigprocmask(SIG_BLOCK, [TTOU], [], 8) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig -icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_START or TCSETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
times({tms_utime=7627, tms_stime=883, tms_cutime=0, tms_cstime=0}) = 441975594
exit_group(1)                           = ?

See also:

http://bugs.darcs.net/issue94

This bug is 100% reproducible on my Linux system and on my Windows system.

To reproduce:

1.  Make it so that there are many changes that darcs will prompt you for, such
as by creating many files and darcs adding them.  "Many" needs to be somewhere
between a dozen and a hundred.
2.  Run "darcs record" and then hold down the "y" key.
3.  Observe:

Shall I record this change? (1/?)  [ynWsfqadjkc], or ? for help: ydarcs:
<stdin>: hSetBuffering: unsupported operation (Illegal seek)


I tried to write a Perl unit test for this, but it doesn't happen when done
programmatically, presumably because GHC behaves differently when input isn't a tty.

Cutting-and-pasting a series of "yyyyyyyyyyyyyyyyyyyyyyyyyy" has the same effect
as holding down the "y" key and triggers this same bug.

When I compiled darcs on windows configure couldn't find term.h (even though it 
was there...) so it didn't use ncurses.  This results in a version of darcs 
that requires you to press enter after each letter.  Or you could hold down the 
key for a while and then press enter to give it a stream of 'y's.  Either way, 
it seems that this bug doesn't get triggered without ncurses support.

So that could be a possible lead for a debugger.

Another way to trigger this error is to start the test suite with 'make test'
and hit a key. The record.pl test will then reliably fail with:

#     Failed test (record.pl at line 23)
#                   'darcs: <stdin>: hSetBuffering: unsupported operation
(Illegal seek)
# 
# '
#     doesn't match '(?i-xsm:Finished recording)'

I sent a patch to darcs-devel that, ehm, sort of maybe ... fix this issue (and
issue94, issue146 and issue318), but it seems to have gone mostly unnoticed. So
I attach it to this issue (for convenience), and ask if anyone can 1) verify it
fixes the problem, and 2) check so it doesn't have any ill effects.

Attachments

• hSetBuffering.dpatch

On Mon, Nov 27, 2006 at 05:28:40PM +0000, Tommy Pettersson wrote:
> I sent a patch to darcs-devel that, ehm, sort of maybe ... fix this issue (and
> issue94, issue146 and issue318), but it seems to have gone mostly unnoticed. So
> I attach it to this issue (for convenience), and ask if anyone can 1) verify it
> fixes the problem, and 2) check so it doesn't have any ill effects.

fwiw, the patch looked reasonable to me.
-- 
David Roundy
Department of Physics
Oregon State University

On Mon, Nov 27, 2006 at 17:57:29 +0000, David Roundy wrote:
> > I sent a patch to darcs-devel that, ehm, sort of maybe ... fix this issue (and
> > issue94, issue146 and issue318), but it seems to have gone mostly unnoticed. So
> > I attach it to this issue (for convenience), and ask if anyone can 1) verify it
> > fixes the problem, and 2) check so it doesn't have any ill effects.
> 
> fwiw, the patch looked reasonable to me.

I could go ahead and just push it for the next round of patches.
This way it would be more likely to get tested.

On Mon, Nov 27, 2006 at 07:01:05PM +0000, Eric Kow wrote:
> > fwiw, the patch looked reasonable to me.
> 
> I could go ahead and just push it for the next round of patches.
> This way it would be more likely to get tested.

That's what I'd do.  I don't understand the error, but I also don't see how
a failure to set the buffering mode could be problematic in any way, so
ignoring it probably won't hurt.
-- 
David Roundy
Department of Physics
Oregon State University

I'm going to resolve this and its cousins.  Please re-open if you object.

I've tried the Zooko test on Windows (Cygwin)

darcs init
i=0; while [ $i -lt 1000 ]; do touch $i; i=$(($i+1)); done
darcs add *
darcs record

And it seems fine.

For info, the patch was in darcs 1.0.9:

Fri Nov 17 23:14:24 CET 2006  Tommy Pettersson <ptp@lysator.liu.se>
  * ignore failure from hSetBuffering