[QA Blocker] All mailnews networking activity is broken

VERIFIED FIXED in M10

Status

P1
blocker
VERIFIED FIXED
19 years ago
10 years ago

People

(Reporter: scottputterman, Assigned: mscott)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.
(Assignee)

Comment 1

19 years ago
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.
(Assignee)

Comment 2

19 years ago
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.
(Reporter)

Comment 3

19 years ago
On the off chance it was me, I tried backing out my change.  It didn't make any
difference.

Updated

19 years ago
Severity: normal → critical

Comment 4

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M10
(Assignee)

Comment 5

19 years ago
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.
(Assignee)

Updated

19 years ago
Summary: IMAP Urls aren't working → [QA Blocker] All mailnews networking activity is broken
(Assignee)

Comment 6

19 years ago
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.

Updated

19 years ago
Severity: critical → blocker
OS: Windows NT → All
Priority: P3 → P1
Hardware: PC → All

Comment 7

19 years ago
upgrading to QA Blocker.  Can't test mail without this.  cc: cyeh - don't know
if tree will be closed until this is fixed.
(Assignee)

Comment 8

19 years ago
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;
}
(Assignee)

Comment 9

19 years ago
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).
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

19 years ago
I've checked this in so I'll mark it fixed now.

Comment 11

19 years ago
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.