Closed Bug 12638 Opened 25 years ago Closed 25 years ago

[QA Blocker] All mailnews networking activity is broken

Categories

(MailNews Core :: Backend, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: scottputterman, Assigned: mscott)

Details

Imap urls aren't working in this morning's build.  If you open a folder, new
headers don't get downloaded and if you click on a message, the message is never
displayed.  The progress bar just spins.
Looking at the build logs from yesterday, putterman was the only one to modify
anything in the imap directory...=)

I haven't even started my morning build yet so it will be a while until I can
check this one out.
Does news and get new mail for pop work in this mornings builds? I know Warren
changed the pipe implementation that is used by socket based protocols last
night...maybe that's what broke.
On the off chance it was me, I tried backing out my change.  It didn't make any
difference.
Severity: normal → critical
Marking critical.  Almost tempted to mark blocker, but we can still do some
testing on POP.  If this is blocking you guys, go ahead and mark blocker.
Status: NEW → ASSIGNED
Target Milestone: M10
accepting and investigating. My current guess is that it has to do with the new
pipe implementation that warren added last night. Or Seth's preferences bug
could also be the problem.
Summary: IMAP Urls aren't working → [QA Blocker] All mailnews networking activity is broken
Apparently in this mornings builds, *ALL* of our socket based protocols are
broken. This is not good.

I'm adding Warren to the cc list as I see he created a new pipe implementation
yesterday. Warren, is there any work mailnews needs to do for your new pipe
implementation? Some how all of our networking stuff broke last night. Maybe
it's related to Rick's M9 branch landing too but I doubt that because M9 works.

Lisa, we should escalate this to blocker status.
Severity: critical → blocker
OS: Windows NT → All
Priority: P3 → P1
Hardware: PC → All
upgrading to QA Blocker.  Can't test mail without this.  cc: cyeh - don't know
if tree will be closed until this is fixed.
I see at least one problem.....

NS_IMETHOIMP nsPipe::nsPipeInputStream::GetLength(PRUint32 *result)

Always returns 0 for the length!!

The result variable is never assigned the length of the stream. Instead, the
nsresult is assigned the length value so the function always returns a failure
code if there are bytes in the stream. *arghhhh*

NS_IMETHODIMP
nsPipe::nsPipeInputStream::GetLength(PRUint32 *result)
{
    nsPipe* pipe = GET_INPUTSTREAM_PIPE(this);
    nsAutoCMonitor mon(pipe);

    PRUint32 len = pipe->mBuffer.GetSize();
    if (pipe->mReadCursor) {
        char* end = (pipe->mReadLimit == pipe->mWriteLimit)
            ? pipe->mWriteCursor
            : pipe->mReadLimit;
        len -= pipe->mBuffer.GetSegmentSize() - (end - pipe->mReadCursor);
    }
    if (pipe->mWriteCursor)
        len -= pipe->mWriteLimit - pipe->mWriteCursor;
    return len;
}
Okay I think I've fixed it.

I've modified GetLength to actually return the length and I also had to remove
the lines that subtracted bytes from the length if the write cursor was greater
than zero. I kept running into a problem where length would be small like 87 and
then pipe->mWriteLimit - pipe->mWriteCursor; would be huge which caused len to
wrap around (because it is an unsigned int).
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I've checked this in so I'll mark it fixed now.
linux (1999-09-10-09 M110
Win_nt 4.0 (1999-09-10-09 M11)
Mac (1999-09-10-09 M11)
This problem has been fixed. If you open a folder, new  headers get downloaded
and if you click on a message, the message displayed.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.