Hm, that's trange, I've been running the same package for 4 days without any problem...

Can you please check package from http://people.redhat.com/stransky/thunderbird/ ? Just download it and rebuild with "rpmbuild --rebuild package" and then install from /usr/src/redhat/RPMS.

(In reply to comment #1)
> Hm, that's trange, I've been running the same package for 4 days without any
> problem...  
Well, the machine exposing this issue had been updated to FC11 from FC10 throughout last weekend and since then is tripping over many F11 stability and FC10/FC11 compatibility issues.

I.e. I have no idea what is the actual cause for the core-dumps, because I had to tweak this machine heavily since upgrading to FC11.

One thing I know: After several core dumps, I found > 200000 (2 hundred thousand) mails in my (imap) trash folder and noticed thunderbird to be busy adding more (seemed like a race condition somewhere - origin? thunderbird, dovecot, ...?). I managed to escape this situtation by launching evolution and having let it clean up this mess. Since then, thunderbird had only crashed once.

BTW: Should you be interested in further investigation, I am still keeping several of the core-dumps around.

(In reply to comment #2)
> Can you please check package from
> http://people.redhat.com/stransky/thunderbird/ ? Just download it and rebuild
> with "rpmbuild --rebuild package" and then install from /usr/src/redhat/RPMS.  
It would have been nice to point me to 
http://koji.fedoraproject.org/koji/buildinfo?buildID=102079 ;)

With these rpms, I haven't encountered a thunderbird core dump yet.

However, I am still observing variants of the other issues I mentioned in comment #1 (Incorrect folder counters etc.). Furthermore, I am suspecting it to be loosing mails - Definitely not ready for production use.

(In reply to comment #3)
> However, I am still observing variants of the other issues I mentioned in
> comment #1 (Incorrect folder counters etc.). Furthermore, I am suspecting it to
> be loosing mails - Definitely not ready for production use.  

Well, how upgraded? Preupgrade or by some unsupported means (yum, snake)? Meaning, it is hard to know whom to blame -- whether there is something screwed up in TB or in your installation.

Anyway, not much to do in triage here. I can certainly not reproduce here (and no I haven't tried to install F10, just to upgrade it to F11), so just if Martin has some idea about what's wrong.

(In reply to comment #4)
> (In reply to comment #3)
> > However, I am still observing variants of the other issues I mentioned in
> > comment #1 (Incorrect folder counters etc.). Furthermore, I am suspecting it to
> > be loosing mails - Definitely not ready for production use.  
> 
> Well, how upgraded? Preupgrade 
By preupgrade,

> or by some unsupported means (yum, snake)?
Pardon, but I am sick of having to listen to these shallow and weak excuses, for some incompetent and non-cooperational guys having allowed to regress something which used to work for years!

While we're at it: preupgrade or livecd installs are not less broken than yum upgrades - You simply might not have noticed it - I tripped these bugs.

> Meaning, it is hard to know whom to blame -- whether there is something screwed
> up in TB or in your installation.
Well, ... it actually doesn't matter. An application dumping a core is always broken and defect, by definition, no matter what the cause is.

> Anyway, not much to do in triage here. I can certainly not reproduce here (and
> no I haven't tried to install F10, just to upgrade it to F11), so just if
> Martin has some idea about what's wrong.  
As I tried to tell you before, I can send you the core dumps, in case you want to debug these issues. 

For now, I am fed up with FC11's poor shape and back to FC10 on this machine.

(In reply to comment #5)
> > or by some unsupported means (yum, snake)?
> Pardon, but I am sick of having to listen to these shallow and weak excuses,
> for some incompetent and non-cooperational guys having allowed to regress
> something which used to work for years!
> 
> While we're at it: preupgrade or livecd installs are not less broken than yum
> upgrades - You simply might not have noticed it - I tripped these bugs.

I am sorry, word "unsupported" was probably unnecessary here.

Seeing the same thing.  And I did a fresh install.  So whatever it is, it's not install related.

#8  0x00007f0c7bb20b3f in __cxa_pure_virtual () from /usr/lib64/libstdc++.so.6
#9  0x00007f0c6c349ff0 in nsImapMockChannel::QueryInterface (this=0x7f0c1933c498, aIID=@0x4777, aInstancePtr=0x7fff1c5cc278)
    at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsImapProtocol.cpp:8144
#10 0x00007f0c7f19e286 in nsQueryInterfaceWithError::operator() (this=0x7fff1c5cc290, aIID=@0x4777, answer=0x6) at nsCOMPtr.cpp:64
#11 0x00007f0c7f19e346 in nsCOMPtr_base::assign_from_qi_with_error (this=0x7fff1c5cc2a0, qi=@0x4777, iid=@0x4777) at nsCOMPtr.cpp:105
#12 0x00007f0c7f19ff15 in nsCOMPtr (qi=<value optimized out>, this=<value optimized out>) at ../../dist/include/xpcom/nsCOMPtr.h:580
#13 NS_GetWeakReference (qi=<value optimized out>, this=<value optimized out>) at nsWeakReference.cpp:108
#14 0x00007f0c6c37316a in do_GetWeakReference (error=<value optimized out>, aRawPtr=<value optimized out>)
    at ../../../mozilla/dist/include/xpcom/nsIWeakReferenceUtils.h:110
#15 nsImapUrl::SetMockChannel (error=<value optimized out>, aRawPtr=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsImapUrl.cpp:1181
#16 0x00007f0c6c32a9d3 in nsImapIncomingServer::RetryUrl (this=0x7f0c77bc0e20, aImapUrl=0x7f0c546a0a00, aChannel=0x6)
    at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsImapIncomingServer.cpp:454
#17 0x00007f0c7f1dd465 in NS_InvokeByIndex_P (that=0x4777, methodIndex=18295, paramCount=6, params=0xffffffffffffffff)
    at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_linux.cpp:208
#18 0x00007f0c7f1d5ddb in nsProxyObjectCallInfo::Run (this=0x7f0c50846d80)
    at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/proxy/src/nsProxyEvent.cpp:181
#19 0x00007f0c7f1d1ab5 in nsThread::ProcessNextEvent (this=0x7f0c77b4f160, mayWait=1, result=0x7fff1c5cc4cc)
    at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/threads/nsThread.cpp:510
#20 0x00007f0c7f1a2984 in NS_ProcessNextEvent_P (thread=0x4777, mayWait=18295) at nsThreadUtils.cpp:227
#21 0x00007f0c6a0d2591 in nsBaseAppShell::Run (this=0x7f0c6dc6a9a0)
    at /usr/src/debug/thunderbird-3.0/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170
#22 0x00007f0c691d18a2 in nsAppStartup::Run (this=0x7f0c6c7484c0)
    at /usr/src/debug/thunderbird-3.0/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:192
#23 0x00007f0c7f6445ca in XRE_main (argc=<value optimized out>, argv=<value optimized out>, aAppData=<value optimized out>)
    at /usr/src/debug/thunderbird-3.0/mozilla/toolkit/xre/nsAppRunner.cpp:3279
#24 0x00000000004019bc in main (argc=1, argv=0x7fff1c5ccd08) at /usr/src/debug/thunderbird-3.0/mail/app/nsMailApp.cpp:103

I've been seeing this consistently on both my Fedora 11 machines (one on i386, the other on x86_64).  Both were upgraded from Fedora 10 (using the DVD).

It's a serious problem.  My normal habit is to ignore my mailer unless it pings me; now, I can't do that, because the mailer can't be trusted to keep running.  I want to upgrade my work machine from F9 to F11, but I can't until Thunderbird can be trusted.

I don't see the weird behavior with Trash filling up (possibly because I rarely delete email).

This is using IMAP over SSL (not TLS).  I have Thunderbird set up with two email accounts (work and home); but it doesn't always access both of them, since the work account requires me to turn on the VPN.  Both accounts are running Dovecot servers; I wouldn't blame it on Dovecot (since Thunderbird on F9 is still fine), but I suppose there might be a bug which gets wiggled only by Dovecot.

Since I did migrate my email accounts over (mv backup/.thunderbird ~/), that could be relevant.

One is imap over TLS (Dovecot).  Two are gmail accounts (Imap over SSL), one is an AOL account (not sure if TLS is on or not), and there is also a local mail folder that isn't used much, and the RSS subscription account.

(In reply to comment #9)
> I don't see the weird behavior with Trash filling up (possibly because I rarely
> delete email).
FWI: I am extensivly using filters to sort mails from several different remote imap and pop3 accounts into local imap folders. 

Provided I repeatedly noticed older thunderbirds to corrupt its filtering rules, I am inclined to believe such an incident might have happened again with thunderbird-3.x.

Is there anything else I can do to help debug this?  It's rather annoying...

(I have no filters.  I use procmail on the server side instead)

I recreated my account information (moved .thunderbird out of the way, and recreated everything.)  It doesn't seem to be crashing now, so it definitely seems to be something about old configurations.

Please could you try to reproduce this by using package from:

http://people.redhat.com/jhorak/thunderbird-3.0-2.5.b3pre.hg.6a6386c16e98.fc11.x86_64.rpm

or (package for i386):

http://people.redhat.com/jhorak/thunderbird-3.0-2.5.b3pre.hg.6a6386c16e98.fc11.i386.rpm

the x86_64 version has been running for a few hours without crashing, which is certainly more than the stock version usually did with the same .thunderbird directory.

Like with its predecessors, on x86_64, I am observing long serious of error messages similar to this:
...
LoadPlugin: failed to initialize shared library /usr/lib/mozilla/plugins/nppdf.so [/usr/lib/mozilla/plugins/nppdf.so: wrong ELF class: ELFCLASS32]
LoadPlugin: failed to initialize shared library /usr/lib/flash-plugin/libflashplayer.so [/usr/lib/flash-plugin/libflashplayer.so: wrong ELF class: ELFCLASS32]
..

No idea why an x86_64 _thunderbird_ should be looking into 32bit mozilla 
/usr/lib/mozilla/plugins and complain about them.


Another observation: I am observing the "spinner" in the upper right corner of thunderbird is permanently spinning. Bug or feature?

thunderbird-2.x doesn't exhibit this behavior.

(In reply to comment #16)
> Like with its predecessors, on x86_64, I am observing long serious of error
Sorry, typo: ... long series of error messages ...

Addition: The "counters are wrong on dovecot imap folders" issue is still present.

A day later, no crashes.  Tons of output (Glib, weak unref errors), but no crashes.

I am not seeing the spinner spinning issue, and I'm not sure what he means by "counters are wrong on dovecot imap folders", but it looks to me on initial glance that the counters are working

(In reply to comment #19)
> A day later, no crashes.
Same here - thunderbird uptime ca. 18 hours, so far.

> I am not seeing the spinner spinning issue,
My comment wasn't quite right. What I actually saw yesterday was the spinner spinner running for a long time (ca. 1 hour) until it finally stopped, which had caused me to think it wasn't stopping.

In the end it finally stopped, but it took a very long time.

No idea why. Wild guess: Has something changed about thunderbird's internal mail boxes/mail box index or similar, causing it reformat existing mail folders upon first start up? As I have several 10000s of mails in my folders, this would at least be an explanation for my observation.

> and I'm not sure what he means by
> "counters are wrong on dovecot imap folders",
On some imap (sub-) folders I am filtering Inbox content to, Thunderbird's "All Folders" overview pan occasionally is reporting bogus "unread message counts",
e.g. I am occasionally observing
[icon] [bold foldername]
instead of
[icon] [bold foldername] (count)

and 
[icon] [bold foldername] (count)
with the folder containing no unread mails.

(In reply to comment #20)
> On some imap (sub-) folders I am filtering Inbox content to, Thunderbird's "All
> Folders" overview pan occasionally is reporting bogus "unread message counts",

I'm pretty sure that's not new; I've seen that occasionally for years.

(In reply to comment #21)
> (In reply to comment #20)
> > On some imap (sub-) folders I am filtering Inbox content to, Thunderbird's "All
> > Folders" overview pan occasionally is reporting bogus "unread message counts",
> 
> I'm pretty sure that's not new; I've seen that occasionally for years.  

Occasionally in the sense of once or twice per year, yes, but with thunderbird-3.* I am seeing them daily.

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.