645976 - libnspr4.so: pop3 crashing on reading truncated mail, after mail was deleted external. [@ nsPop3Sink::CheckPartialMessages(nsIPop3Protocol*)]

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: POP, defect)

Description

[Henry N.]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.16) Gecko/20110319 SUSE/3.6.16-0.2.1 Firefox/3.6.16
Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) Gecko/20110314 Thunderbird/3.3a3

Reading the rest of previous truncated mail crash the pop3 reader, if the mail was removed via an external program in the meanwhile.

Reproducible: Always

Steps to Reproduce:
1. Set limit size for mail (example 100K). Have preview enabled (F8).
2. Send your self a bigger mail (200K) and get it via POP3.
3. It's shown as "Truncated".
4. Leave TB open with preview of this mail!
5. Go into a Web interface (http://mail.google.com) and remove that mail.
6. Click "Load the rest" in the preview.
Actual Results:  
Crash

Expected Results:  
An error, that mail does not exist, or so.


Crash reports:
libnspr4.so@0x2c229 https://crash-stats.mozilla.com/report/index/bp-a3555faf-5001-454a-b158-2d3e72110114
libnspr4.so@0x2d5f9 https://crash-stats.mozilla.com/report/index/bp-48726b4b-a8b8-4a9a-b265-710c62110329

This bug does not effect, if TB was closed and restarted or by clicking "Get Mail" after the mail was removed external.

Comment 1

[Henry N.]

A more recent BuildID: 20110328030023 Thunderbird/3.3a4pre
Crash Signature:
nsCOMPtr_base::~nsCOMPtr_base | nsPop3Sink::CheckPartialMessages
Crash report:
https://crash-stats.mozilla.com/report/index/91bfc7d7-7e56-428b-adae-0ad5a2110329

Comment 2

[Wayne Mery (:wsmwk)]

Hi Henry. Thanks for the detailed report.

can you get a pop3:5  protocol log per https://wiki.mozilla.org/MailNews:Logging


bp-91bfc7d7-7e56-428b-adae-0ad5a2110329
SIGSEGV
0x200000002
0	libxul.so	nsCOMPtr_base::~nsCOMPtr_base	nsCOMPtr.cpp:81
1	libxul.so	nsPop3Sink::CheckPartialMessages	mailnews/local/src/nsPop3Sink.cpp:256
2	libxul.so	nsPop3Sink::AbortMailDelivery	mailnews/local/src/nsPop3Sink.cpp:536
3	libxul.so	nsPop3Protocol::GetStat	mailnews/local/src/nsPop3Protocol.cpp:2342
4	libxul.so	nsPop3Protocol::ProcessProtocolState	mailnews/local/src/nsPop3Protocol.cpp:3923
5	libxul.so	nsMsgProtocol::OnDataAvailable	mailnews/base/util/nsMsgProtocol.cpp:387
6	libxul.so	nsInputStreamPump::OnStateTransfer	netwerk/base/src/nsInputStreamPump.cpp:510 

which pretty much matches up to the trio of bugs that might all be the same but never got attention - bug 536800, bug 557122, bug 617844

Comment 3

[Henry N.]

Attachment: pop3:5 protocol log

(In reply to comment #2)
Pop3 log attached.

Correspond to this crash report:
https://crash-stats.mozilla.com/report/index/bp-8b1dd454-65f0-434f-8e1b-d00d72110329

Comment 4

[Wayne Mery (:wsmwk)]

bienvenu, 

Is this protocol log sufficient to understand the crash?

bp-3ffe6784-c264-469d-986f-078cf2111122 also cites henry's steps, namely "I download just the headers of an email - A colleague downloads the entire email and removes the copy from the server - I then click on the 'Download the rest of the email' option - Thunderbird crashes"

none of the other bugs - bug 536800, bug 557122, bug 617844 - have protocol logs

Comment 5

[David :Bienvenu]

looks like partialMsg is null - not sure why that would happen, but it's fairly easy to add a null check.

Comment 6

[:aceman]

bienvenu, what is that function actually trying to do? The comments say like it would delete partial messages that were deleted from the server? Why would we want that? Isn't that causing bug 714090 ?

Comment 8

[David :Bienvenu]

(In reply to :aceman from comment #6)
> bienvenu, what is that function actually trying to do? The comments say like
> it would delete partial messages that were deleted from the server? Why
> would we want that? Isn't that causing bug 714090 ?

If the message is gone from the server, and we've only got a partial message on the client, there's no point in keeping it around, because we have no hope of ever getting the whole message from the server.

Comment 9

[:aceman]

What if the user does not want the full message and is content with the stub?
See bug 714090 and bug 288465. I also think removing the partial messages forcibly under their hands is unexpected.

Comment 10

[Wayne Mery (:wsmwk)]

potentially related bugs https://bugzilla.mozilla.org/buglist.cgi?type1-0-0=substring;list_id=2838752;field0-0-0=short_desc;bug_severity=blocker;bug_severity=critical;bug_severity=major;bug_severity=normal;type0-0-1=substring;field0-0-1=keywords;type1-0-1=allwordssubstr;resolution=---;classification=Client%20Software;classification=Components;query_format=advanced;longdesc=part%20trunc;value0-0-1=crash;type0-0-0=anywordssubstr;value0-0-0=part%20trunc;component=Networking%3A%20POP;field1-0-0=short_desc;product=MailNews%20Core;product=Thunderbird;longdesc_type=anywordssubstr;field1-0-1=short_desc

This isn't the oldest bug on the topic, but I suggest we make this the one to fix, and work backwards from here.

Comment 11

[David :Bienvenu]

(In reply to :aceman from comment #9)
> What if the user does not want the full message and is content with the stub?
> See bug 714090 and bug 288465. I also think removing the partial messages
> forcibly under their hands is unexpected.

My experience is that they'll file bugs because they try to download the complete message and it fails, not understanding that it has been deleted from the server.

Comment 12

[:aceman]

Then the link should vanish and be replaced by the explanation text ;)

Comment 13

[Wayne Mery (:wsmwk)]

ref also:
bug 248742 Loss of header-only message (junk, offline, dragged) ... related to Bug 288465 Moving partially downloaded messages causes message to be lost.

Comment 14

[David :Bienvenu]

(In reply to :aceman from comment #12)
> Then the link should vanish and be replaced by the explanation text ;)

Yes, and file | offline get selected messages should check for this. This is all to say the fix is not simply to just not delete the messages anymore. It's quite a bit more involved.

Comment 15

[:aceman]

What about including the warning "this incomplete message will be deleted locally if it is deleted on the server" into the current placeholder (with the download link) that shows in an incomplete message?

Comment 16

[David :Bienvenu]

(In reply to :aceman from comment #15)
> What about including the warning "this incomplete message will be deleted
> locally if it is deleted on the server" into the current placeholder (with
> the download link) that shows in an incomplete message?

Maybe "If it is no longer on the server" instead of "deleted on the server". But most of the time, we would know if the message is on the server before we display the link, in which case we can be more specific.

Comment 17

[:aceman]

(In reply to David :Bienvenu from comment #16)
> But most of the time, we would know if the message is on the server before
> we display the link, in which case we can be more specific.

How do we know without pinging the server?

Comment 18

[Vasil Dimov [:vd]]

Hello,

I fetched an old tree (hg update -rTHUNDERBIRD_3_3a3_RELEASE) which the reporter of this bug used and was able to crash TB just as described. The backtrace from the old tree crash is:

#0  0x0000000802898216 in NS_LogCOMPtrRelease_P (aCOMPtr=0x80d2d90e0, 
    aObject=0xfffffe5c) at BlockingResourceBase.h:351
#1  0x00000008023bb4d6 in ~nsCOMPtr (this=0x80d2d90e0) at nsTDependentString.h:65
#2  0x00000008024fbfbe in ~partialRecord (this=0x80d2d90e0)
   from /usr/w/obj-tb/mozilla/dist/bin/libxul.so
#3  0x00000008024fc5aa in nsPop3Sink::CheckPartialMessages (this=0x80c8cae00, 
    protocol=0x80fd8bfe0) from /usr/w/obj-tb/mozilla/dist/bin/libxul.so
#4  0x00000008024fdf3a in nsPop3Sink::AbortMailDelivery (this=0x80c8cae00, 
    protocol=0x80fd8bfe0) from /usr/w/obj-tb/mozilla/dist/bin/libxul.so
#5  0x00000008024f52a1 in nsPop3Protocol::GetStat (this=0x80fd8bf00) at nsID.h:87
#6  0x00000008024f9ec0 in nsPop3Protocol::ProcessProtocolState (this=0x80fd8bf00, 
    url=0x810afee08, aInputStream=0x80c088758, sourceOffset=220, aLength=9)
    at nsID.h:87
#7  0x00000008023e7df0 in nsMsgProtocol::OnDataAvailable (this=0x80fd8bf00, 
    request=0x80c6e3300, ctxt=0x810afee08, inStr=0x80c088758, sourceOffset=220, 
    count=9) at nsID.h:87
#8  0x0000000800f29d19 in nsInputStreamPump::OnStateTransfer (this=0x80c6e3300)
    at nsTSubstring.h:478
#9  0x0000000800f2986d in nsInputStreamPump::OnInputStreamReady (this=0x80c6e3300, 
    stream=0x80c088758) at nsTSubstring.h:478
#10 0x0000000802858905 in nsInputStreamReadyEvent::Run (this=0x80d614080)
    at AutoRestore.h:122
#11 0x00000008028831e1 in nsThread::ProcessNextEvent (this=0x80c26d3c0, mayWait=1, 
    result=0x7fffffffd23c) at nsID.h:87
#12 0x0000000802811386 in NS_ProcessNextEvent_P (thread=0x80c26d3c0, mayWait=1)
    at nsThreadUtils.h:258
#13 0x000000080227045b in nsBaseAppShell::Run (this=0x80c09a9b0) at nsVoidArray.h:63
#14 0x0000000801f952a3 in nsAppStartup::Run (this=0x80c648740)
   from /usr/w/obj-tb/mozilla/dist/bin/libxul.so
#15 0x0000000800ef21a2 in XRE_main (argc=1, argv=0x7fffffffdb10, 
    aAppData=0x80c09a080) at nsID.h:87
#16 0x0000000000400df8 in main (argc=1, argv=0x7fffffffdb10)
    at /usr/w/m/tb/comm-central/mail/app/nsMailApp.cpp:101

I cannot reproduce this crash on the latest tree (12025:62db600f84f1). This bug must have already been fixed.

Notice that Bug 695625 (which has been set as a duplicate of this one) uses a slightly different scenario to crash TB:

* This bug: fetch headers only: OFF, Download max 100K and send yourself a >100K email
* Bug 695625: fetch headers only: ON, Download max - irrelevant

Both scenarios produce the same backtrace on THUNDERBIRD_3_3a3_RELEASE and both do not crash on a recent tree.

Comment 19

[Wayne Mery (:wsmwk)]

Thanks vd!

WFM based on vd comment 18.

Comment 20

[Wayne Mery (:wsmwk)]

(In reply to :aceman from comment #17)
> (In reply to David :Bienvenu from comment #16)
> > But most of the time, we would know if the message is on the server before
> > we display the link, in which case we can be more specific.
> 
> How do we know without pinging the server?

aceman, If your question is unanswered, you'll need to ask someone other than bienvenu