Thunderbird segfaults while checking mail from a POP account wich sends some lines twice in the answer to the LIST command [@ PL_strdup] [@ nsPop3Protocol::GetMsg]

RESOLVED WORKSFORME

Status

--
critical
RESOLVED WORKSFORME
11 years ago
7 years ago

People

(Reporter: nicolas.bonifas, Unassigned)

Tracking

({crash})

1.8 Branch
x86
Linux
crash

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(5 attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.3) Gecko/20070310 Iceweasel/2.0.0.3 (Debian-2.0.0.3-1)
Build Identifier: 1.5.0.7

Hello,
Thunderbird often segfaults when I check my mails.
I use a buggy pop3 server: it sent twice some lines in the answer to the UIDL command. In the function GetList (nsPop3Protocol.cpp), m_listpos is incremented at each line of the UIDL answer. m_listpos becomes finally greater than the number of messages, which causes the crash in the line: if(!m_pop3ConData->msg_info[m_listpos-1].msgnum)
Attached is a full backtrace from Icedove 1.5.0.9.dfsg1-1 (from Debian).
This bug has been in Debian Bug Tracking System for 1 year (http://bugs.debian.org/390230).
As this bug is due to a grave bug in the server, I don't know if you will want to correct it.
Thanks,
Nicolas

Reproducible: Always
(Reporter)

Comment 1

11 years ago
Created attachment 273402 [details]
Gdb backtrace

Updated

11 years ago
Severity: normal → critical
Component: General → MailNews: Backend
Keywords: crash
Product: Thunderbird → Core
QA Contact: general → backend
Summary: Thunderbird segfaults while checking mail from a POP account wich sends some lines twice in the answer to the UIDL command → Thunderbird segfaults while checking mail from a POP account wich sends some lines twice in the answer to the UIDL command [@ PL_strdup] [@ nsPop3Protocol::GetMsg]
Version: unspecified → 1.8 Branch

Updated

11 years ago
Component: MailNews: Backend → Networking: POP
QA Contact: backend → networking.pop

Comment 2

11 years ago
I'm having trouble reproducing this bug via testing and I can't see what the problem is when looking into the code.

The line if(!m_pop3ConData->msg_info[m_listpos-1].msgnum)
you say it's crashing on seems to have been inserted by you according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=390230#30.
In our code I can't see we're dereferencing m_pop3ConData->msg_info if m_listpos > m_pop3ConData->number_of_messages. m_listpos indeed can get greater than number_of_messages but isn't then.

I don't wanna say there's no bug but I can't help right now.
But I'd be interested in a log of your POP transaction (please see http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#pop how to create one). 

Regarding your backtrace
#2  0xb7db9495 in PL_strdup (s=0x8975798 "112695870š^·4491") at strdup.c:53
#3  0xb521e0b1 in put_hash (table=0x89757b0, key=0x8a58ef0 
"1126958738.14354", value=<value optimized out>, dateReceived=1166983101) at nsPop3Protocol.cpp:166
#4  0xb5222d6f in nsPop3Protocol::GetMsg (this=0x892e410) at nsPop3Protocol.cpp:2746

That's interesting because it looks the content of key has changed between entering put_hash and PL_strdup.
That point in GetMsg is also interesting because this code is only reached if you have downloaded a messagem, left it on server and later switched off "Leave messages on server". So that's no normal every day retrieval.
(Reporter)

Comment 3

11 years ago
Created attachment 278756 [details]
Log of a transaction (part 1)

Concatenate pop3log.bz2a and pop3log.bz2b before running bzip2 -d
(Reporter)

Comment 4

11 years ago
Created attachment 278757 [details]
Log of a transaction (part 2)
(Reporter)

Comment 5

11 years ago
Created attachment 278758 [details]
Standard output when Thunderbird crashed.
(Reporter)

Comment 6

11 years ago
I made a new try with Icedove 1.5.0.10. Attached are standard output when Thunderbird crashed and the log of the POP3 transaction. Please tell me if you need more informations (core dump, or detailed backtrace).
Regards,
Nicolas

Comment 7

11 years ago
Sorry, no. There is a double line in LIST response though not in UIDL response. But I can't see why that could cause this trouble.
The crash appears to always happen in an malloc but called from different code. Something must damage some structure and cause a crash later on.
Is this crash from a standard Icedove or with your patch?

David, do you see anything striking?
(Reporter)

Comment 8

11 years ago
It is a standard Icedove (Debian package version 1.5.0.10.dfsg1-3).

Comment 9

11 years ago
I agree that memory looks like it's been corrupted, leading to a crash later on. So the crash stack may just be where the corruption is encountered, but not where it happened.  Running with some sort of heap checker might help pin point where the corruption happens.

Are there any 2.0 based Debian packages that you could try, to see if the problem has been fixed in 2.0?

Comment 10

11 years ago
I should also say that I can't read the logs - bza2 files aren't recognized by winrar...
(Reporter)

Comment 11

11 years ago
I tried with Icedove 2.0.0.4 (Debian package version 2.0.0.4.dfsg1-2), and it still crashes.
To open pop3log.bz2, you have to concatenate pop3log.bz2a and pop3log.bz2b before using bzip2 -d.

Thanks for your interest in this bug.
(Reporter)

Updated

11 years ago
Summary: Thunderbird segfaults while checking mail from a POP account wich sends some lines twice in the answer to the UIDL command [@ PL_strdup] [@ nsPop3Protocol::GetMsg] → Thunderbird segfaults while checking mail from a POP account wich sends some lines twice in the answer to the LIST command [@ PL_strdup] [@ nsPop3Protocol::GetMsg]

Comment 12

11 years ago
is there any way to get Christian or myself access to a test account on this server, so we can reproduce the crash for ourselves?
(Reporter)

Comment 13

11 years ago
I can not provide you with an account on the server, but I made a test program that sends duplicate LIST informations (one line is sent twice every 10 lines). Thunderbird's behaviour is exactly the same as when I use the real buggy server.
(Reporter)

Comment 14

11 years ago
Created attachment 278991 [details]
Test program

Usage:
1) compile with gcc -o fakepop3 fakepop3.c
2) launch ./fakepop3 [port_number] (without port_number parameter, default is 110)
3) create an account in Thunderbird
   server is localhost, user and password can be anything
4) before checking mail, uncheck the "leave messages on server" box: this server doesn't support the "DELE" pop3 command

Comment 15

11 years ago
Thanks for your test program. Unfortunately it does crash TB trunk as little as my own test script did. It also doesn't crash TB 1.5.0.9. So maybe the result of the memory corruption is system dependent.

But there might indeed have been a problem in builds before 2007-06-27 in which
m_pop3ConData->msg_info[i].uidl = PL_strdup(uid);
got assigned (several times actually) while i was equal m_pop3ConData->number_of_messages and thus 1 greater than the array we allocate. This was fixed in revision 1.270 of nsPop3Protocol.cpp.

If this caused the crash you experience it should be gone in current nightlies. So I ask you to test a stock linux build from http://ftp.eu.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-trunk/.
(Reporter)

Comment 16

11 years ago
I tried with the build from 31-Aug-2007 04:13, and it did not crash, neither with the test program nor on the real server!
Thanks everyone for your help!

Comment 17

11 years ago
I'm pleased to read this. To verify that the result isn't influenced by the build environment you could also test a mozilla release build e.g. from http://releases.mozilla.org/pub/mozilla.org/thunderbird/releases/1.5.0.7/linux-i686/en-US/.
(Reporter)

Comment 18

11 years ago
It doesn't crash, and I can't crash Icedove 2.0.0.4 anymore. No libs were updated since yesterday, so I really can't understand why the bug vanished.

Comment 19

11 years ago
Now that's mysterious. I can only say keep it on your radar.
(Reporter)

Updated

11 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
(Assignee)

Updated

7 years ago
Crash Signature: [@ PL_strdup] [@ nsPop3Protocol::GetMsg]
You need to log in before you can comment on or make changes to this bug.