Open
Bug 164288
Opened 23 years ago
Updated 3 years ago
In the WINNT build incoming data may be lost after PR_IO_TIMEOUT_ERROR from PR_Recv
Categories
(NSPR :: NSPR, defect)
Tracking
(Not tracked)
NEW
People
(Reporter: wtc, Unassigned)
Details
In the WINNT build of NSPR, incoming data may
be lost after a PR_Recv call fails with the
PR_IO_TIMEOUT_ERROR or PR_PENDING_INTERRUPT_ERROR.
This problem won't be noticed if you immediately
close the socket after the PR_IO_TIMEOUT_ERROR
or PR_PENDING_INTERRUPT_ERROR, but may occur if
you call PR_NT_CancelIo and then try to receive
data from the socket again.
The incoming data will be lost with the following
sequence of events.
1. PR_Recv times out or is interrupted by another
thread. The 'io_suspended' flag of the thread is
set to PR_TRUE.
2. Before the thread calls PR_Close or PR_NT_CancelIo
on the socket, the overlapped I/O completes and the
completion packet is posted to NSPR's I/O completion
port. Note that incoming data have been placed in
the buffer passed to the PR_Recv call.
3. An NSPR "CPU idle" thread reads the completion
packet, sees that the thread is already running
(because its 'io_suspended' flag is true), and
goes on to read the next completion packet.
Nothing is done to the incoming data in the buffer
passed to the PR_Recv call; the data are lost.
A similar problem may exist for PR_Accept.
For PR_Send, the outgoing data may still be
sent even if PR_Send times out or is interrupted
by another thread. This may be a problem in
some cases.
Reporter | ||
Comment 1•23 years ago
|
||
The best way to fix this bug and the similar problems
with PR_Accept and PR_Send is to have these NSPR I/O
functions call NT's CancelIo function after a timeout or
interrupt. If the overlapped I/O completes before we
can cancel it, these I/O functions will return with the
result of the completed overlapped I/O instead of the
timeout or interrupt error.
If we can implement this fix, PR_NT_CancelIo will no
longer be necessary. It will become a no-op and be
deprecated.
Status: NEW → ASSIGNED
Updated•19 years ago
|
QA Contact: wtchang → nspr
Comment 2•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: wtc → nobody
Status: ASSIGNED → NEW
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•