Original bug line: http:/ /lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsSocketTransport.cpp#972 , in implement of nsWriteToSocket() len = PR_Write(fd, fromRawSegment, count); I think it should be: len = PR_Write(fd, fromRawSegment + toOffset, count); It could just be a lapsus calami:-)

Should be looked at, thus confirming. toOffset is an unused parameter.

When I hack nsStockTransport by a NSPR-IO-layer of mine, I find if PR_Write return a value less than "count", nsSocketTransport will make second call on PR_Write for sending remaining data in internal buffer "mWriteBuffer", at this time, toOffset>0, but the bug line will just send the data that it have sent. So, should change sending buffer pointer to fromRawSegment+toOffset

adding relevant people.

hmmm... it looks like you're right. I think that the rawSegment offset should be used in both nsReadFromSocket(...) and nsWriteToSocket(...). Is that right warren? That the offset argument represents an offset into the raw segment?? -- rick

The offset represents the offset from the beginning of the stream (as I recall).

hey warren, are you sure? I'm talking about the offset argument in the function being passed to ReadSegments and WriteSegments... -- rick

Ok, looking at nsWriteToRawBuffer / nsReadFromRawBuffer in nsPipe2.cpp, I see that the offset is relative to the destination / source buffers, respectively.

so it sounds like the offset should be added into the rawSegment in both nsReadFromSocket(...) and nsWriteToSocket(...). Gagan, will you do this? -- rick

I don't think so. RawSegment is the internal buffer and has nothing to do with the logical offset.

I thought that the offset represented the offset into the rawSegment... no? -- rick

->ruslan

Comparing to nsPipe2.cpp's nsWriteToRawBuffer, I don't think the proposed fix is correct. The offset if relative to the destination for 'write', not to the internal buffer. If anything, we should assert if toOffset isn't 0 since you can't seek on a socket.

However, in nsSocketTransport there's another case when it writes directly from the stream, and it that case I think the offset is the offset from the buffer?

Putting on [nsbeta2-] radar. Not critical to beta2.

pulling in ruslan's necko bugs ->darin

The bug just hit out when return value of PR_Write() is less than length of data that caller wanna send. Although necko used a no block socket, this status is unfamiliar, so the bug seem deathly. But when we run mozilla on a slowly network, the bug could jump out:-( We can recur this bug use a hacked PR_Write() returning a smaller value advisedly.

*** This bug has been marked as a duplicate of 54081 ***

VERIFIED/dupe