Bug 507524 - pure virtual method called (core dumped)
pure virtual method called (core dumped)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: thunderbird (Show other bugs)
11
All Linux
high Severity urgent
: ---
: ---
Assigned To: Jan Horak
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-23 03:06 EDT by Ralf Corsepius
Modified: 2010-06-28 09:14 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-28 09:14:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ralf Corsepius 2009-06-23 03:06:21 EDT
Description of problem:

Thunderbird dumps core while browsing email:
# thunderbird
...
pure virtual method called
terminate called without an active exception
/usr/lib64/thunderbird-3.0b2/run-mozilla.sh: line 131:  7079 Aborted                 (core dumped) "$prog" ${1+"$@"}


Version-Release number of selected component (if applicable):
thunderbird-3.0-2.3.beta2.fc11.x86_64

How reproducible:
Not always and non-deterministic, but fairly frequently.
Current MTBCD (mean time between core dump) < 10 minutes.

Steps to Reproduce:
1. launch thunderbird
2. browse, read email, get mail ...
  
Actual results:
core dump, due sig 6, cf. below

Expected results:
Function.

Additional info:

* gdb traceback:
...
Core was generated by `/usr/lib64/thunderbird-3.0b2/thunderbird-bin'.
Program terminated with signal 6, Aborted.
#0  0x0000003be520ed5b in raise () from /lib64/libpthread.so.0
(gdb) where
#0  0x0000003be520ed5b in raise () from /lib64/libpthread.so.0
#1  0x0000003bef41f308 in nsProfileLock::FatalSignalHandler (signo=6) at nsProfileLock.cpp:212
#2  <signal handler called>
#3  0x0000003be46332f5 in raise () from /lib64/libc.so.6
#4  0x0000003be4634b20 in abort () from /lib64/libc.so.6
#5  0x0000003bee8c3e15 in __gnu_cxx::__verbose_terminate_handler () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:93
#6  0x0000003bee8c2236 in __cxxabiv1::__terminate (handler=0x1ba7) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
#7  0x0000003bee8c2263 in std::terminate () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#8  0x0000003bee8c2b3f in __cxxabiv1::__cxa_pure_virtual () at ../../../../libstdc++-v3/libsupc++/pure.cc:50
#9  0x00007f0a68049ff0 in nsImapMockChannel::QueryInterface (this=0x7f0a55429a98, aIID=@0x1ba7, aInstancePtr=0x7fff777d3d98)
    at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsImapProtocol.cpp:8144
#10 0x0000003bf0039286 in nsQueryInterfaceWithError::operator() (this=0x7fff777d3db0, aIID=@0x1ba7, answer=0x6) at nsCOMPtr.cpp:64
#11 0x0000003bf0039346 in nsCOMPtr_base::assign_from_qi_with_error (this=0x7fff777d3dc0, qi=@0x1ba7, iid=@0x1ba7) at nsCOMPtr.cpp:105
#12 0x0000003bf003af15 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 0x00007f0a6807316a 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 0x00007f0a6802a9d3 in nsImapIncomingServer::RetryUrl (this=0x7f0a6f4b5cc0, aImapUrl=0x7f0a54aa8400, aChannel=0x6)
    at /usr/src/debug/thunderbird-3.0/mailnews/imap/src/nsImapIncomingServer.cpp:454
#17 0x0000003bf0078465 in NS_InvokeByIndex_P (that=0x1ba7, methodIndex=7079, 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 0x0000003bf0070ddb in nsProxyObjectCallInfo::Run (this=0x7f0a55375b80) at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/proxy/src/nsProxyEvent.cpp:181
#19 0x0000003bf006cab5 in nsThread::ProcessNextEvent (this=0x7f0a6f44f160, mayWait=1, result=0x7fff777d3fec)
    at /usr/src/debug/thunderbird-3.0/mozilla/xpcom/threads/nsThread.cpp:510
#20 0x0000003bf003d984 in NS_ProcessNextEvent_P (thread=0x1ba7, mayWait=7079) at nsThreadUtils.cpp:227
#21 0x00007f0a65dd2591 in nsBaseAppShell::Run (this=0x7f0a6f39a2e0) at /usr/src/debug/thunderbird-3.0/mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170
#22 0x00007f0a64ed18a2 in nsAppStartup::Run (this=0x7f0a68444b00) at /usr/src/debug/thunderbird-3.0/mozilla/toolkit/components/startup/src/nsAppStartup.cpp:192
#23 0x0000003bef4195ca 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=0x7fff777d4828) at /usr/src/debug/thunderbird-3.0/mail/app/nsMailApp.cpp:103

* I am observing other weirdnesses with this thunderbird, e.g. imap folder mail counts not being updated correctly and imap folders being marked "containing unread mails" while not displaying these unread mails.
Comment 1 Martin Stransky 2009-06-23 04:39:04 EDT
Hm, that's trange, I've been running the same package for 4 days without any problem...
Comment 2 Martin Stransky 2009-06-23 06:20:14 EDT
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.
Comment 3 Ralf Corsepius 2009-06-24 00:57:14 EDT
(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.
Comment 4 Matěj Cepl 2009-06-24 09:48:32 EDT
(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.
Comment 5 Ralf Corsepius 2009-06-24 11:07:07 EDT
(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.
Comment 6 Matěj Cepl 2009-06-24 12:31:38 EDT
(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.
Comment 7 Douglas Kilpatrick 2009-07-04 13:41:48 EDT
Seeing the same thing.  And I did a fresh install.  So whatever it is, it's not install related.
Comment 8 Douglas Kilpatrick 2009-07-05 10:50:32 EDT
#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
Comment 9 John Stracke 2009-07-07 09:04:59 EDT
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.
Comment 10 Douglas Kilpatrick 2009-07-07 09:14:59 EDT
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.
Comment 11 Ralf Corsepius 2009-07-12 03:38:05 EDT
(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.
Comment 12 Douglas Kilpatrick 2009-07-12 23:29:38 EDT
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)
Comment 13 Douglas Kilpatrick 2009-07-13 20:22:08 EDT
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.
Comment 15 Douglas Kilpatrick 2009-07-15 11:03:40 EDT
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.
Comment 16 Ralf Corsepius 2009-07-15 11:27:18 EDT
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.
Comment 17 Ralf Corsepius 2009-07-15 11:28:17 EDT
(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 ...
Comment 18 Ralf Corsepius 2009-07-15 12:51:30 EDT
Addition: The "counters are wrong on dovecot imap folders" issue is still present.
Comment 19 Douglas Kilpatrick 2009-07-15 19:32:51 EDT
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
Comment 20 Ralf Corsepius 2009-07-16 00:42:39 EDT
(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.
Comment 21 John Stracke 2009-07-16 09:00:46 EDT
(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.
Comment 22 Ralf Corsepius 2009-07-16 09:51:44 EDT
(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.
Comment 23 Bug Zapper 2010-04-27 11:11:20 EDT
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
Comment 24 Bug Zapper 2010-06-28 09:14:34 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.