Closed Bug 10138 Opened 25 years ago Closed 25 years ago

[PP] [blocker] can't view more than one message under POP

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jay, Assigned: rods)

Details

if you open up messenger and try to view you mail, you can view the first
message selected in the two frames below the list of email (the header and
body)...but if you try to select another email to view, nothing happens.

Steps:
1. Launch messenger
2. Open an account folder in the sidebar, goto Inbox
3. Click on a message in the top right frame...see it in the two frames below.
4. Try to click on another message...nothing changes in the header and body
frames (the old message is still displayed).

Machine and Build:
Mac 8.5.1 build 1999071911
Assignee: phil → bienvenu
Local mail or IMAP? This was working for me with imap in today's build. Lisa, do
you see this problem?
Summary: can't view more than one message → [PP] can't view more than one message
The platform on this is on the Mac.  I'll ask Peter to confirm.  (Peter, is this
occurring for you?)

I know today's Win32 builds are fine.
This is only a problem with Mac build 1999071911...and i am using a POP3
account.
Summary: [PP] can't view more than one message → [PP] can't view more than one message under POP
Yes, this problem is occuring on today PPC Commercial seamonkdy build 1999-07-19-
11-m9.  The problem occurs only under POP.  Under IMAP, I can view multiple mail
messages ok.
Summary: [PP] can't view more than one message under POP → [PP] [blocker] can't view more than one message under POP
Pls fix this for tomorrow's release build.  Very hard to test under this
circumstance.  Thanks.
Can anyone with a mac help me out here? With Paul's help, I was able to
determine that we're not spooling the second message out the tempMessage.emf
file, but I don't know where it's failing. Without a mac, I won't be able to fix
this, obviously.
Adding hangas to the cc list as well to bring in all of our mac gurus.
Sorry, I thought I had added Paul...
Ok, I will take a look at it..
result of my first investigation:

The first message you have selected is reloaded every time to try to display
another message. You can fix manually the problem by deleting the temporary file
tempMessage.eml (at the same level that apprunner). Something goes wrong with
this temp file, it seems to stay open even after the message is displayed, thing
that may explains why it will failed next time we try to open it! I am still
investigating...
JFD or bienvenu, you might want to start by tracing through the the build log to
see what got checked into local during the past week. Maybe there is a
corelation there.
closing the steam does not seem to release/close the file anymore. I suspect
looking at changes in the steam code would be more productive.
Yes, closestream doesn't seems to close the file anymore!
I have a fix for it. As nsFileSpecImpl::closeStream just release the io stream, thing that never close the file!, we

need to do it manually.

Index: nsMailboxProtocol.cpp

===================================================================

RCS file: /cvsroot/mozilla/mailnews/local/src/nsMailboxProtocol.cpp,v

retrieving revision 1.51

diff -r1.51 nsMailboxProtocol.cpp

163a164,168

> 	{

> 		nsCOMPtr<nsIOutputStream> outputStream;

> 		m_tempMessageFile->GetOutputStream(getter_AddRefs(outputStream));

> 		if (outputStream)

> 			outputStream->Close();

164a170

> 	}



David, let me know if you want me to check in the fix?
I think there's something more going on here....release shouldn't close the
stream. Only when the ref count goes to zero should it be released.
Not having looked at this at all, my theory would be that last week someone made
a change to local which introduced a memory leak of the mailbox protocol
instance.

by leaking the protocol instance we would be leaking the file stream which would
prevent it from getting closed.

I don't disagree with your fix it seems good to add it. But if someone
introduced a leak we should figure out where....
Scott, you are right. My fix is temporary...
Jeff, did you add a flush to nsMailboxProtocol.cpp? I think that could be
causing our problem.
Assignee: bienvenu → rods
sorry, Jeff, not you at all. It was a change to nsIFileStream.cpp made Friday
that introduced a ref-counting bug. Rod, your change to get an nsISupports adds
an extra reference to the file stream object, so it never gets released, and the
file never gets closed, which means no one else can use the file. If you have
any questions, or disagree, please let me know! I'm going to try to find a fix,
but I don't want to break this code, so I'm reassigning to you.
OK, adding NS_RELEASE as follows in nsIFileStream -
NS_NewTypicalOutputFileStream

    if (NS_OK == rv &&
        NS_OK ==
supports->QueryInterface(nsCOMTypeInfo<nsIOutputStream>::GetIID(),
                                          (void**)&outStr)) {
      *aResult = outStr;
	  NS_RELEASE(supports);

seems to fix the problem. JF, could you try this?
Ahh excellent catch david B. If you check in that change can you change the
NS_OK == stuff to use the NS_SUCCEEDED macro?

rod, you may want to look at using nsCOMPtr for the supports variable if
you end up revisiting that code...that would have prevented this leak I think...
Not only NS_NewTypicalOutputFileStream() requires to call NS_RELEASE(supports)
but also NS_NewTypicalInputFileStream() requires to call NS_RELEASE(supports).
Both routines call NS_NewIOFileStream() which adds a ref count to the supports.
A second QueryInterface() for inStr/OutStr adds another ref count. A
NS_RELEASE(supports) sounds like a must in these two routines.
Too much nsCOMPtr... Sorry, for all of you wasting time on my check in

Here's what I will check in when the tree goes green:
    *aResult = nsnull;
    if (NS_SUCCEEDED(rv)) {
      if
(NS_SUCCEEDED(supports->QueryInterface(nsCOMTypeInfo<nsIOutputStream>::GetIID(),
(void**)&outStr))) {
        *aResult = outStr;
      }
      NS_RELEASE(supports);
    }
    return rv;
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Checked in the fix.
Status: RESOLVED → VERIFIED
Verified in the Mac Seamonkey Commercial build 1999072208-m9 build.  I can view

more than one message under POP.  I also tried it under IMAP and I can view more

than one message.



Verified as fixed.
*** Bug 95469 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.