12 Sep
2005
12 Sep
'05
2:43 p.m.
That's easy enough to fix. The ioctls need to pass down their own event
object and not rely on signaling of the file object.
Ge van Geldorp wrote:
I'm working on bug 713
(http://www.reactos.com/bugzilla/show_bug.cgi?id=713
for the click-happy). What I have found is this:
- Telnet opens a socket
- Sending and receiving are handled by different threads, let's call them S
and R
- Thread R starts a recv() operation, which is translated to an ioctl on the
socket
- No data is available, so thread R blocks, waiting for FileObject->Event
- I type something, which is handled by thread S. Thread S starts a send()
operation.
- Again translated to an ioctl on the socket. Since this is the same socket
as used by S, the FileObject will be the same
- The send can complete immediately, IoCompleteRequest is called which sets
the FileObject->Event.
- Thread R is unblocked, the event it was waiting for was set by thread S.
However, the irp of thread R was never completed. The recv() call returns
with bogus info.
- Thread R starts another recv(). When some data arrives from the server,
two irps are waiting for it. This eventually leads to the crash.
The fundamental problem seems to be multiple overlapping I/O operations
which all use FileObject->Event to signal their completion. I have no idea
how to fix that...
Gé van Geldorp.