default   Racket Bugs
Main PageQuick QueryStandard QueryAdvanced QueryHelp
Log in

View Problem Report: 12860

send email to interested parties or send email followup to audit-trail
Reporter's email: tonyg at ccs dot neu dot edu
Number: 12860
Category: all
Synopsis: Corrupted input in read-bytes-evt when using alarm-evt too
Class: sw-bug
Responsible: mflatt
Notify-List:
Severity: serious
Priority: medium
State: closed
Confidential: no
Arrival-Date: Wed Jun 20 20:32:01 -0400 2012
Closed-Date: Thu Jun 21 22:06:44 -0400 2012
Last-Modified: Sun Jun 24 09:40:38 -0400 2012
Originator: Tony Garnock-Jones
Organization: plt
Submitter-Id: unknown
Release: 5.2.0.7 and 5.2.1.5
Environment: OS X and Linux, at least
Description: When `sync`ing on `read-bytes-evt` at the same time as on `alarm-evt`,
it seems that if the `read-bytes-evt` would have come ready but the
`alarm-evt` is the one actually chosen, the input from
`read-bytes-evt` gets corrupted. This only seems to happen if a single
`read-bytes-evt` instance is reused! If a fresh `read-bytes-evt` is
constructed every time, the input stream remains uncorrupted.

To see this, run `racket buggy-server.rkt 0`, which uses a single
`read-bytes-evt` instance but does not use any `alarm-evt`
instances. In another terminal, run `./run-test-osx.sh` (or
`./run-test-linux.sh`, as appropriate). The program
`./run-test-osx.sh` should terminate without producing any output.

Now, kill off the instance of `buggy-server.rkt`, and start another,
this time by running `racket buggy-server.rkt 1`. This instance uses
both a single `read-bytes-evt` instance and an `alarm-evt`
instance. Now, running `./run-test-osx.sh` should still produce no
output, but in fact on most runs, some output (from diffing the input
against the output of the socket) is produced, meaning that the echoed
output differed from the input.
File Attachments:
How-To-Repeat: Here's a complete small program (base64 tarball with a .rkt file and test data) demonstrating the problem:

H4sIALho4k8AA+1Z3W/bNhDva/VXXBOgkTDLkRzLRh+2YMPy0IdtQFGgD0NR0xJlcZFEl6Ti
uNgfvztSlpWkabYhH1urAxJJvOPd7754UiJkuGxWx88ekqIomicJ2OvMXaPJ1F1bgjiez6Pp
bDqZJhDFkyRJnkHyoKhaarRhCqEYWW9XX5BDsTz/Ar/1o7v+T0i4/OPPahtqri64Gqtzc682
MB6z6fTW/E8mky7/k5NphPlP5tHsGUT3iuIW+sbzf1iyegWKpefcHC+Z5p7nK/6xEYrvVk26
Dm4srqUyAcpmPBc1B79i5zxkJVNVyAMPwG/vLwz434GfNkrx2oQoe8lSE1aiLIXmqawzHUAS
BUFfmY/rNU+NkHVYsDoruQJRg2wMbIQpnJ3TwNopuYFSyjXuak1eAxN4z4EIPWAZce11uTVc
W3jxDHUHVhkK6W2dgi/yvqFWAfgbxdZ2T2epZNUyY+B/CPDeorhiG5zNoAMBNccOIx12Za/R
CXrPrVindqmDdolkC17jEgE/Bcd57uuS8zVE4yh2zxslDHfeoQyFzK3nZaOLEB/XGERa7Sm2
wHcuXUG8x+dzmdsbjNV1lB96utJSao5pRjMh1UhPvuM6FI5toQRX018xTLbl9rNNyW4lsHQM
r7EofKzN0D25DVM4NL26sJzQJaZNsA0QLPx3TBiBpY/l1TMD38PoSomBX/NNiUbxrh/DVpsD
FF6wssGA+65IA4eLpSlfmw7srsJMQSGGf1Dj5M3eExcrG6Pk1atXVlHmyut3H5uUlaf7fktl
VaHykDwImVo1Fa5ixx0d+gfxAbp3aN7/m72R3Zvv9vJSY964UlLBkYV2cHa5Ru94Bn01sFMD
HH1Ej4/iI6A90dH4IHiPnj31efitUTv/35z9+PMvZ+Mqewgbd87/eHLt/W8ancTD/H8MOoSf
mhUdPG/sXD/S8Pr4t1PPe0fDZkHTcEGnpMSHq3NzAcwA9jBoVnEwAn8xbeW6yb8YecKA5rzS
KIniOFZpxw1NG9mUGRTsgtNp4WbQFpaNNeD1FILQVoOkoyQ1eF6VW0gLHCr1yDLs4IFcycq7
YWXFjUb9SjVrPJfG8LYQBBg1tBAlQliv0W/EyUCj3yW/qUbUWAp1ygmL4o3m2Qt4TRtyxXVx
0zmhPTyhtVGNPQ5p/m9tvPqIkc1Zhfro8NTQ1HucnvdWEkKUFnoEqqFU2GTB9bd2iBYj2BQi
LQBx6b/jBAU5kyhbS0ObcB5u+yn0dpJ6DK9r5Ep7bhuuKlGzssUzPsZLiNpNKPXlWBcL8KXy
+ut4/DeWM6I6wTgruVaCGR5QJjjg80qxyvucLl3YAmmN4vimCUmTEjdlTerG+BbcZMaA/So3
IzjHV0yQed5GufVX5rC4HjaChG8BdBCYnYcjj8Lt6nq5JS9rMnNr5ONFW1CdJcqAt0RlXRo+
Uxs7YbLP6s8GfgzWnQ7B7fHRhlx2MeGYUM8FZGSTjC2eY8tQh1ZSG9KH1aSp3dq3Qp/aBjKR
52Snq02PragmXbPvXiBdVLWkYATUCa3VbAQVZ7VT0B4QHBuUZy0Yq58rbARrrbMyHib/k1A7
/2+06X3auOvvP/HJvJv/8WSG8382zP9HosMXx0tRH+vCS6ldqQTcRPoT8EM4/AgJfl2nrCzo
zLDfGz84qbadX760Hd3f2WMPTf1fp+v970bK/dq4u/+79/94Np3T3/+S6GTo/8egL/f/0Ppf
O7X9v8/hA9i44/t/uv//TzKPowl9/8+iaOj/xyC2TDOerwrxx3lZ4SfD+qPSprnYXG4/Ecsb
+AN/4A/8gT/wB/7Xx3/q94+BBhro6egvw007zAAoAAA=
Fix:
Release-Note:
Unformatted:

send email to interested parties or send email followup to audit-trail

Audit Trail:

Responsible changed from "nobody" to "mflatt" by mflatt at racket-lang.org at Thu, 21 Jun 2012 22:06:44 -0400
Reason>>> A commit by mflatt at racket-lang.org has resolved this report
  http://git.racket-lang.org/plt/commit/d253b89ba8
State changed from "open" to "closed" by mflatt at racket-lang.org at Thu, 21 Jun 2012 22:06:44 -0400
Reason>>> A commit by mflatt at racket-lang.org has resolved this report
  http://git.racket-lang.org/plt/commit/d253b89ba8
From: Tony Garnock-Jones <tonyg at ccs.neu.edu>
To: tonyg at ccs.neu.edu, bugs at racket-lang.org, bug-notification at racket-lang.org,
        mflatt at racket-lang.org
Cc: 
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt
 too
Date: Fri, 22 Jun 2012 00:00:11 -0400

 Thanks for that Matthew! That's working well for read-bytes-evt.
 However, the same problem crops up if read-bytes!-evt is used instead of
 read-bytes-evt, which is a bit weird.
 
 I've put the test program, modified to use read-bytes!-evt (reusing the
 same event and buffer each time around), up on github at
 https://github.com/tonyg/racket-pr12860 - is there still a problem
 remaining to be fixed, or have I done something silly in my code?
 
 Regards, and thanks again,
   Tony
From: Matthew Flatt <mflatt at cs.utah.edu>
To: Tony Garnock-Jones <tonyg at ccs.neu.edu>
Cc: "bugs at racket-lang.org" <bugs at racket-lang.org>,
        "bug-notification at racket-lang.org" <bug-notification at racket-lang.org>,
        "mflatt at racket-lang.org" <mflatt at racket-lang.org>
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt too
Date: Fri, 22 Jun 2012 13:35:44 +0800

 Hm, yes, I should have checked that. Inthis case, I think the docs may promise more than the implementation can deliver, but I'll look into it more.
 
 
 
 On Jun 22, 2012, at 12:00 PM, Tony Garnock-Jones <tonyg at ccs.neu.edu> wrote:
 
 > Thanks for that Matthew! That's working well for read-bytes-evt.
 > However, the same problem crops up if read-bytes!-evt is used instead of
 > read-bytes-evt, which is a bit weird.
 > 
 > I've put the test program, modified to use read-bytes!-evt (reusing the
 > same event and buffer each time around), up on github at
 > https://github.com/tonyg/racket-pr12860 - is there still a problem
 > remaining to be fixed, or have I done something silly in my code?
 > 
 > Regards, and thanks again,
 >  Tony
 > 
 
From: Tony Garnock-Jones <tonyg at ccs.neu.edu>
To: Matthew Flatt <mflatt at cs.utah.edu>
Cc: "bugs at racket-lang.org" <bugs at racket-lang.org>,
        "bug-notification at racket-lang.org" <bug-notification at racket-lang.org>,
        "mflatt at racket-lang.org" <mflatt at racket-lang.org>
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt
 too
Date: Sat, 23 Jun 2012 08:01:26 -0400

 On 2012-06-22 1:35 AM, Matthew Flatt wrote:
 > Hm, yes, I should have checked that. Inthis case, I think the docs may promise more than the implementation can deliver, but I'll look into it more.
 
 Thanks. Your fix for read-bytes-evt has let me continue with my work, so
 this is much less urgent, to me at any rate :-)
 
 Regarding read-bytes!-evt, though, I should point out I'm not doing any
 concurrent synchronisation: all I'm doing is reusing a read-bytes!-evt
 instance in a loop. Without the alarm event, everything works fine; with
 the alarm event, the input is corrupted.
 
 I don't mind the buffer being overwritten, er, optimistically during the
 sync call, but I was surprised that the bytes were *consumed* (or
 somehow reordered - I haven't quite gotten to the bottom of the nature
 of the corruption itself) when the read-bytes!-evt was ready but not
 selected.
 
 Cheers,
   Tony
From: Matthew Flatt <mflatt at cs.utah.edu>
To: Tony Garnock-Jones <tonyg at ccs.neu.edu>
Cc: "bugs at racket-lang.org" <bugs at racket-lang.org>,
        "bug-notification at racket-lang.org" <bug-notification at racket-lang.org>
Subject: Re: all/12860: Corrupted input in read-bytes-evt when using alarm-evt
 too
Date: Sun, 24 Jun 2012 07:33:59 -0600

 At Sat, 23 Jun 2012 08:01:26 -0400, Tony Garnock-Jones wrote:
 > Regarding read-bytes!-evt, though, I should point out I'm not doing any
 > concurrent synchronisation: all I'm doing is reusing a read-bytes!-evt
 > instance in a loop.
 
 Yes, but the implementation of `read-bytes!-evt' requires a thread in
 the background. A lack of any way to atomically cancel that thread when
 another event is selected is essentially the problem that I have in
 mind (and I think it's a deep, N-way-rendezvous kind of problem).
 
 > I don't mind the buffer being overwritten, er, optimistically during the
 > sync call, but I was surprised that the bytes were *consumed* (or
 > somehow reordered - I haven't quite gotten to the bottom of the nature
 > of the corruption itself) when the read-bytes!-evt was ready but not
 > selected.
 
 I will push a change the implementation and the guarantees of
 `read-bytes!-evt' that weakens the guarantees but also makes your
 example work.
 

----------
A commit by mflatt at racket-lang.org was marked as relevant
  http://git.racket-lang.org/plt/commit/c11527494e