13.53 KB, text/plain
244.14 KB, application/octet-stream
199.87 KB, application/octet-stream
1.21 KB, application/octet-stream
1.75 KB, application/gzip
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20070310 Iceweasel/18.104.22.168 (Debian-22.214.171.124-1) Build Identifier: 126.96.36.199 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 188.8.131.52.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
Severity: normal → critical
Component: General → MailNews: Backend
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
Component: MailNews: Backend → Networking: POP
QA Contact: backend → networking.pop
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.
Created attachment 278756 [details] Log of a transaction (part 1) Concatenate pop3log.bz2a and pop3log.bz2b before running bzip2 -d
I made a new try with Icedove 184.108.40.206. 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
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?
It is a standard Icedove (Debian package version 220.127.116.11.dfsg1-3).
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?
I should also say that I can't read the logs - bza2 files aren't recognized by winrar...
I tried with Icedove 18.104.22.168 (Debian package version 22.214.171.124.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.
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]
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?
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.
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
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 126.96.36.199. 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/.
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!
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/188.8.131.52/linux-i686/en-US/.
It doesn't crash, and I can't crash Icedove 184.108.40.206 anymore. No libs were updated since yesterday, so I really can't understand why the bug vanished.
Now that's mysterious. I can only say keep it on your radar.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
Crash Signature: [@ PL_strdup] [@ nsPop3Protocol::GetMsg]
You need to log in before you can comment on or make changes to this bug.