389241 - 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]

Status: RESOLVED WORKSFORME

(MailNews Core :: Networking: POP, defect)

Description

[Nicolas Bonifas]

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

Comment 1

[Nicolas Bonifas]

Attachment: Gdb backtrace

Comment 2

[Christian Eyrich]

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.

Comment 3

[Nicolas Bonifas]

Attachment: Log of a transaction (part 1)

Concatenate pop3log.bz2a and pop3log.bz2b before running bzip2 -d

Comment 4

[Nicolas Bonifas]

Attachment: Log of a transaction (part 2)

Comment 5

[Nicolas Bonifas]

Attachment: Standard output when Thunderbird crashed.

Comment 6

[Nicolas Bonifas]

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

[Christian Eyrich]

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?

Comment 8

[Nicolas Bonifas]

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

Comment 9

[David :Bienvenu]

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

[David :Bienvenu]

I should also say that I can't read the logs - bza2 files aren't recognized by winrar...

Comment 11

[Nicolas Bonifas]

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.

Comment 12

[David :Bienvenu]

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?

Comment 13

[Nicolas Bonifas]

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.

Comment 14

[Nicolas Bonifas]

Attachment: 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

[Christian Eyrich]

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/.

Comment 16

[Nicolas Bonifas]

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

[Christian Eyrich]

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/.

Comment 18

[Nicolas Bonifas]

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

[Christian Eyrich]

Now that's mysterious. I can only say keep it on your radar.