unique stacktrace according to simple-dup-finder
which evo version is this exactly?

Used to be RC, now it is 2.6.0, behaves the same way.

could be the same as bug 335558

Mentioned in https://launchpad.net/distros/ubuntu/+source/evolution/+bug/38455 as well:


Debugging Information:

Backtrace was generated from '/usr/bin/evolution'

Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1231980864 (LWP 8183)]
[New Thread -1278567504 (LWP 8232)]
[New Thread -1259598928 (LWP 8230)]
[New Thread -1251206224 (LWP 8229)]
[New Thread -1240630352 (LWP 8197)]
0xffffe410 in __kernel_vsyscall ()

+ Trace 67517

debug backtrace:

(gdb) bt

+ Trace 67521

i assume that bug 335558 and bug 340402 are duplicates, but i'm not sure

Other ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/evolution/+bug/42762

Comment from https://launchpad.net/distros/ubuntu/+source/evolution/+bug/42411 which is about that too:

"It crashes when I close it. But only when I have enabled "Empty Trash Folders on Exit [Every Time]", so it must be happening when it empties the trash."

*** Bug 340402 has been marked as a duplicate of this bug. ***

*** Bug 343304 has been marked as a duplicate of this bug. ***

335558 does not look like a duplicate to me.

*** Bug 343498 has been marked as a duplicate of this bug. ***

+ Trace 68596

$1 = (EShellWindowPrivate *) 0xbfff9d88
(gdb) print *priv
$2 = {shell = 0xbfff9da8, shell_view = 0x805c357, menu = 0x8400038, component_views = 0x84f3d98, paned = 0x86c8e98, sidebar = 0x89e78c,
  sidebar_notebook = 0x89e78c, view_notebook = 0x805c310, statusbar_notebook = 0xbfff9dc8, ui_component = 0xda41aa, current_view = 0x83ff534,
  tooltips = 0x84f3d98, status_bar = 0x561fb69, offline_toggle = 0xbfff9e7c, offline_toggle_image = 0x84068c8, menu_hint_label = 0x89e78c,
  store_window_size_timer = 3221200392}
(gdb) print p
Variable "p" is not available.
(gdb) list
1209    {
1210            EShellWindowPrivate *priv = window->priv;
1211            ComponentView *view = NULL;
1212            GSList *p;
1213
1214            for (p = priv->component_views; p != NULL; p = p->next) {
1215                    ComponentView *this_view = p->data;
1216
1217                    if (strcmp (this_view->component_id, component_id) == 0
1218                        || (this_view->component_alias != NULL
(gdb) print priv->component_views
$3 = (GSList *) 0x84f3d98
(gdb) print priv->component_views->next
$4 = (GSList *) 0x84e5300
(gdb) print priv->component_views->next->next
$5 = (GSList *) 0x0
(gdb) print component_id
$6 = 0x84f3d98 "mail"
(gdb) print this_view->component_id
No symbol "this_view" in current context.
(gdb) print priv->component_views
$7 = (GSList *) 0x84f3d98
(gdb) print priv->component_views->data
$8 = 0x6c69616d
(gdb) print ((ComponentView *)(priv->component_views->data))->component_id
Cannot access memory at address 0x6c696171
(gdb) print ((ComponentView *)(priv->component_views->next->data))->component_id
Cannot access memory at address 0x1c04
(gdb)

Looks like all the priv->component_views items were already deref-ed.  There seems to be a race here between the main window's finalize/dispose and timers that are fired when the window closes.

*** Bug 344703 has been marked as a duplicate of this bug. ***

*** Bug 346332 has been marked as a duplicate of this bug. ***

*** Bug 346887 has been marked as a duplicate of this bug. ***

*** Bug 346937 has been marked as a duplicate of this bug. ***

quite a few duplicates, targetting to 2.6

*** Bug 347919 has been marked as a duplicate of this bug. ***

*** Bug 348066 has been marked as a duplicate of this bug. ***

This bug is targetted to 2.6 but I got a crash which I think is the same as this with version 2.7.90-0ubuntu2. The backtrace:

+ Trace 69751

Some aditional info:

(gdb) list
1210            GSList *p;
1211
1212            for (p = priv->component_views; p != NULL; p = p->next) {
1213                    ComponentView *this_view = p->data;
1214
1215                    if (strcmp (this_view->component_id, component_id) == 0
1216                        || (this_view->component_alias != NULL
1217                            && strcmp (this_view->component_alias, component_id) == 0)) {
1218                            view = p->data;
1219                            break;
(gdb) frame

+ Trace 69752

$7 = (ComponentView *) 0x80cf308
(gdb) print this_view->component_id
$8 = 0x0
(gdb) print component_id
$9 = 0x8292f60 "mail"

*** Bug 349500 has been marked as a duplicate of this bug. ***

Another stacktrace with debugging symbols and probably good description (at the end) in duplicate bug 349500.

*** Bug 349603 has been marked as a duplicate of this bug. ***

*** Bug 349636 has been marked as a duplicate of this bug. ***

In my computer it always crashes, wether the empty trash bin option is set or not.

----

Distribution: Ubuntu 6.06 (dapper)
Package: Evolution
Severity: critical
Version: GNOME2.14.2 2.6.x
Gnome-Distributor: Ubuntu
Synopsis: Evolution always crashes on exit
Bugzilla-Product: Evolution
Bugzilla-Component: Mailer
Bugzilla-Version: 2.6.x
BugBuddy-GnomeVersion: 2.0 (2.14.1)
Description:
Description of the crash:

It always crashes, even if the "empty trash bin" option is not set.

Steps to reproduce the crash:
1. open evolution
2. close evolution
3. crash

Expected Results:


How often does this happen?

Always


Additional Information:



Debugging Information:

Backtrace was generated from '/usr/bin/evolution-2.6'

(no debugging symbols found)
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1232155744 (LWP 29510)]
[New Thread -1320932432 (LWP 29523)]
[New Thread -1279566928 (LWP 29522)]
[New Thread -1288066128 (LWP 29520)]
[New Thread -1296458832 (LWP 29518)]
[New Thread -1270776912 (LWP 29516)]
[New Thread -1262347344 (LWP 29512)]
[New Thread -1253954640 (LWP 29511)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0xffffe410 in __kernel_vsyscall ()

+ Trace 69962

*** Bug 350004 has been marked as a duplicate of this bug. ***

*** Bug 350152 has been marked as a duplicate of this bug. ***

Set target milestone to 2.8

*** Bug 350783 has been marked as a duplicate of this bug. ***

This vresion: Evolution 2.6.1
It sometimes was slow to close & on occasion ubuntu would pop-up its "not responding" window, which would close "on its own" - after afew seconds- with evolution. No problems following or at new start-up.
This was a result of the "Bug Report Tool", announcing the crash - to me.

*** Bug 350899 has been marked as a duplicate of this bug. ***

*** Bug 350867 has been marked as a duplicate of this bug. ***

OK peoples we need to create a gnome based desktop that is very able to work like the Windows Vista and MacOSX desktops and is able to read windows and any other Unix/linux system out there that can be installed back to back with this Fedora project and I need to be trained in the art of this gDesklets system. I can be reached at tecgnull@comcast.net and if you need to speek to me Sunday threw Saturday email me first with your comments and ideas. I am interested in anything that I can assist with. For those whom are intersted in donating some ideas and money to my affect with in my affort in the open source community. Please email me first and I will get to you as soon as I can with directions in supporting my piece of this establishment.

bug 351088 providea an uptodate stacktrace (2.7.91) with line numbers

*** Bug 351088 has been marked as a duplicate of this bug. ***

the problem I originall y reported in http://bugzilla.gnome.org/show_bug.cgi?id=347919 appears to be sorted out in the latest fedora update, evolution-2.6.3-1.fc5.5 .. If others experience the same, I can consider this bug resolved. 

*** Bug 351872 has been marked as a duplicate of this bug. ***

*** Bug 352282 has been marked as a duplicate of this bug. ***

still on 2.7.91

And _this_ problem still exists on evolution-2.6.3-1.fc5.5 in FC5

I'm curious how this bug differs from bug 347919 with regards to the stack traces. 

Created attachment 71339 [details]
backtrace generated by bugbuddy

Comment on attachment 71339 [details]
backtrace generated by bugbuddy

well what do you know, it crashed while idling in the background for no discernable reason. fun. here's the backtrace.

*** Bug 352316 has been marked as a duplicate of this bug. ***

*** Bug 352527 has been marked as a duplicate of this bug. ***

*** Bug 352691 has been marked as a duplicate of this bug. ***

*** Bug 352751 has been marked as a duplicate of this bug. ***

*** Bug 352867 has been marked as a duplicate of this bug. ***

*** Bug 352939 has been marked as a duplicate of this bug. ***

Two comments on https://launchpad.net/distros/ubuntu/+source/evolution/+bug/38455 indicate that the bug seems to be fixed for them.

*** Bug 353263 has been marked as a duplicate of this bug. ***

*** Bug 353349 has been marked as a duplicate of this bug. ***

*** Bug 353492 has been marked as a duplicate of this bug. ***

*** Bug 353631 has been marked as a duplicate of this bug. ***

Created attachment 71962 [details] [review]
Patch to fix the bug

This patch should fix the bug. Sorry, I haven't compiled it since no development version for evo here, but the idea is clear - we have timeout that works after view destruction and we should clear it.

I think this fix should go into GNOME 2.16/ Evolution 2.8

*** Bug 353688 has been marked as a duplicate of this bug. ***

*** Bug 353689 has been marked as a duplicate of this bug. ***

*** Bug 353692 has been marked as a duplicate of this bug. ***

*** Bug 353884 has been marked as a duplicate of this bug. ***

*** Bug 353896 has been marked as a duplicate of this bug. ***

Nickolay:

Speaking a someone who isn't an evo developer, but has seen this sort of bug before (and you did ask for a review on ddl):

You shouldn't you be using g_object_set_data on emfv *after* you have unref-ed emfv. That is asking for trouble.

The code assumes that el and emfv will get valid results from g_object_get_data (this may be valid, I don't know). However, el and emfv are only unref-ed if v is valid. Shouldn't they be unref-ed regardless?

I'd also be tempted to move the call to view_change_timeout_remove closer to the beginning of the impl_dispose function.I base this on experience with similar bugs I enountered in gnome-games rather than firm knowledge; I haven't chased up the timer routine to see if it uses activity_handler, search_context or local_store (in which case you would definitely need to move it up).

*** Bug 354107 has been marked as a duplicate of this bug. ***

Created attachment 72161 [details] [review]
Patch

Thanks Callum for comments, I've updated patch according to them to make it more clear what's going on.

Nickolay, Callum : Thanks for the patch and review love.

On reading the code, the rationale of preventing the trigger of the timeout after view destruction appears correct and adequate to get rid of the problem.

But knowing little about the latent assumptions the mailer may have on the component view lifecycle and the timing of review - I really prefer one of the mail hackers to have a look at the change and express their views as well. I've poked them and hopefully I can wrap the review/approval/commit steps in time for the release.

Thanks for your patience.

Thanks Nickolay. It seems good to me and I now see what the unrefs are trying to do. Of course this just means that the patch has reached the limits of my competence to spot errors...

Thanks Nickolay. Patch looks good. Approved for commiting (after release-team approval for freeze-break)

However, as said in the code-comment, we need to have a new View object for handling these things and get rid of the hack (using g_object_set on the component_view) for better coding. 

Patch committed to HEAD. 

Per previous comment, update patch status and resolve the bug as fixed.
Thanks to the GNOME release team for the approving the hard code freeze break.

*** Bug 354253 has been marked as a duplicate of this bug. ***

*** Bug 354301 has been marked as a duplicate of this bug. ***

Great, thanks to all for operative work.

*** Bug 354311 has been marked as a duplicate of this bug. ***

*** Bug 354530 has been marked as a duplicate of this bug. ***

*** Bug 354783 has been marked as a duplicate of this bug. ***

*** Bug 355092 has been marked as a duplicate of this bug. ***

*** Bug 355538 has been marked as a duplicate of this bug. ***

*** Bug 356689 has been marked as a duplicate of this bug. ***

This crash is still happening to me with version 2.8.0, the backtrace is the same as before.

Rui, can you please provide a backtrace? It doesn't crash for me. Can you also make sure that your evolution aren't linked with the old components.

*** Bug 357478 has been marked as a duplicate of this bug. ***

*** Bug 357729 has been marked as a duplicate of this bug. ***

*** Bug 357725 has been marked as a duplicate of this bug. ***

(In reply to comment #82)
> Rui, can you please provide a backtrace? It doesn't crash for me. Can you also
> make sure that your evolution aren't linked with the old components.
> 

Well I'm using ubuntu edgy with the following packages and versions:

$ dpkg -l | grep evolution
ii  evolution                             2.8.0-0ubuntu3                       The groupware suite
ii  evolution-data-server                 1.8.0-0ubuntu1                       evolution database backend server
ii  evolution-data-server-common          1.8.0-0ubuntu1                       architecture independent files for Evolution
ii  evolution-dbg                         2.8.0-0ubuntu3                       The groupware suite - with debugging symbols
ii  evolution-exchange                    2.8.0-0ubuntu1                       Exchange plugin for the Evolution groupware 
ii  evolution-plugins                     2.8.0-0ubuntu3                       All bundled plugins for Evolution
ii  evolution-webcal                      2.8.0-0ubuntu1                       webcal: URL handler for GNOME and Evolution
ii  libebook1.2-9                         1.8.0-0ubuntu1                       Client library for evolution address books
ii  libecal1.2-7                          1.8.0-0ubuntu1                       Client library for evolution calendars
ii  libedata-book1.2-2                    1.8.0-0ubuntu1                       Backend library for evolution address books
ii  libedata-cal1.2-6                     1.8.0-0ubuntu1                       Backend library for evolution calendars
ii  libedataserver1.2-7                   1.8.0-0ubuntu1                       Utility library for evolution data servers
ii  libedataserverui1.2-8                 1.8.0-0ubuntu1                       GUI utility library for evolution data serve
ii  libexchange-storage1.2-2              1.8.0-0ubuntu1                       Backend library for evolution calendars

and I have never installed local versions of any of these components.

Here's the backtrace:

(gdb) thread apply all bt

+ Trace 73385

1218            GSList *p;
1219
1220            for (p = priv->component_views; p != NULL; p = p->next) {
1221                    ComponentView *this_view = p->data;
1222
1223                    if (strcmp (this_view->component_id, component_id) == 0
1224                        || (this_view->component_alias != NULL
1225                            && strcmp (this_view->component_alias, component_id) == 0)) {
1226                            view = p->data;
1227                            break;
(gdb) print component_id
$1 = 0x82d3b98 "mail"
(gdb) print this_view->component_id
$2 = 0x0
(gdb) 

seems to still happen on 2.8.0, see comment #86 and bug 358085. reopening.

*** Bug 358085 has been marked as a duplicate of this bug. ***

*** Bug 358166 has been marked as a duplicate of this bug. ***

*** Bug 358181 has been marked as a duplicate of this bug. ***

Hm, it looks strange, but I can't reproduce this problem. 

Rui, can you help a bit with debugging, it's not quite clear for me when does view->component_id becames 0. Can you add some debug printing to the function component_view_free to see if it's invoked before the setTitle call? Do it really freed before quit?

*** Bug 358216 has been marked as a duplicate of this bug. ***

*** Bug 358286 has been marked as a duplicate of this bug. ***

Ok, I did what you said, though I'm not sure it helps:

=== modified file 'shell/e-shell-view.c'
--- shell/e-shell-view.c        2006-09-29 13:11:52 +0000
+++ shell/e-shell-view.c        2006-09-29 13:24:28 +0000
@@ -47,6 +47,8 @@

        e_shell_window_set_title(esw->window, id, tmp);
        g_free(tmp);
+
+       g_message("=====> setTitle");
 }

 static void

=== modified file 'shell/e-shell-window.c'
--- shell/e-shell-window.c      2006-09-29 13:11:52 +0000
+++ shell/e-shell-window.c      2006-09-29 13:20:08 +0000
@@ -168,6 +168,8 @@
        g_free (view->component_id);
        g_free (view->component_alias);
        g_free (view);
+
+       g_message("=====> component_view_free");
 }

 static void


And right before the crash this is what gets printed:

get tiagomatos@gmail.com pop://tiagomatos%40gmail.com@pop.gmail.com/
Find Items 0
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free


If you need more info I'll gladly provide it.

*** Bug 358857 has been marked as a duplicate of this bug. ***

Hm, component_view_free calls unref on MailComponent (mail/mail-component.c) and this function should remove view_changed_timeout in impl_dispose. Rui, can you check that with another printf

Actually we can solve this crash by just checking for NULL in EShellWindow::setTitle or by looking for destroy of window in EShellView (there is comment with TODO in e-shell-view.c about that). I wonder if it will be acceptable.

For me it's still interesting why after shell destruction component is still alive. Probabaly somebody has a leaked reference on it.

*** Bug 358870 has been marked as a duplicate of this bug. ***

(In reply to comment #96)
> Hm, component_view_free calls unref on MailComponent (mail/mail-component.c)
> and this function should remove view_changed_timeout in impl_dispose. Rui, can
> you check that with another printf

Ok, I made this further change:

=== modified file 'mail/mail-component.c'
--- mail/mail-component.c       2006-09-29 13:11:52 +0000
+++ mail/mail-component.c       2006-10-02 10:58:10 +0000
@@ -442,6 +442,8 @@
 
        view_changed_timeout_remove ((EComponentView *)object);
 
+       g_message("=====> view_changed_timeout_remove (%p)", object);
+
        if (priv->activity_handler != NULL) {
                g_object_unref (priv->activity_handler);
                priv->activity_handler = NULL;


But it seems this function isn't called. The output:

get tiagomatos@gmail.com pop://tiagomatos%40gmail.com@pop.gmail.com/
Find Items 0
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> setTitle
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free
evolution-shell-Message: =====> component_view_free


At this point evolution crashed with exactly the same backtrace as I already posted.

*** Bug 359693 has been marked as a duplicate of this bug. ***

this bites too many people, GNOME 2.16 target.

*** Bug 360036 has been marked as a duplicate of this bug. ***

*** Bug 360220 has been marked as a duplicate of this bug. ***

*** Bug 360176 has been marked as a duplicate of this bug. ***

*** Bug 360661 has been marked as a duplicate of this bug. ***

*** Bug 360639 has been marked as a duplicate of this bug. ***

Im not able to see this bug in my machine what so ever I try. Can some one try this hack? Im not sure. Im doing this to identify the problem.

Created attachment 74360 [details] [review]
Proposed patch

Created attachment 74362 [details] [review]
Alternative patch

I also can't reproduce this bug. I suspect we have a leak of mail-component reference somewhere, so the mail component is not destroyed. But I propose this patch which is less hackish and fixes one TODO as well. It should fix the problem by ignoring setTitle calls.

Created attachment 74363 [details] [review]
Alternative patch in unified diff

Nickolay, are you sure this fixes the problem? I had a printf in dispose of e-shell-window:dispose that gets called before this. there could be some more time for another crash.

No idea, now I can't reproduce this bug at all. But from the backtrace you can see that e_shell_window_set_title is called from impl_ShellView_setTitle and right, it happens after the dispose of EShellWindow but I suspect EShellView is still alive since ORBit calls it. EShellView has pointer to EShellWindow and TODO states that this pointer should be invalidated after the dispose. 

With the patch after dispose callback will set pointer to NULL and e_shell_window_set_title won't be called.

Probably Rui can help with testing.

*** Bug 361328 has been marked as a duplicate of this bug. ***

(In reply to comment #112)
> Probably Rui can help with testing.
> 

I've been running evolution 2.8.1-0ubuntu2 with your last patch for 2 days and it hasn't crashed on me yet. I wouln't take it as fixed though since this crash isn't completely reproducible. The only thing I know that improves the odds of it happening is quiting evo when displaying mail on my IMAP account.

*** Bug 361703 has been marked as a duplicate of this bug. ***

*** Bug 361715 has been marked as a duplicate of this bug. ***

*** Bug 361846 has been marked as a duplicate of this bug. ***

Confirming again, just for the fun of it...

Ill go ahead and commit my patch. Im sure that the function wont be called again, when object is being destroyed. Let us observe this as this isnt always reproducible when we wanted to fix it :)

*** Bug 361931 has been marked as a duplicate of this bug. ***

*** Bug 361902 has been marked as a duplicate of this bug. ***

I committed my patch to head and stable (Yes I guess harish branched today morning). I would prefer to have the bug open and observe it atleast in 2.9.1 and later close it when it is not at all reproducible.

marking patch 74360 as "committed":
http://cvs.gnome.org/viewcvs/evolution/shell/e-shell-window.c?r1=1.55&r2=1.56 .

*** Bug 362130 has been marked as a duplicate of this bug. ***

*** Bug 362119 has been marked as a duplicate of this bug. ***

*** Bug 362162 has been marked as a duplicate of this bug. ***

*** Bug 362231 has been marked as a duplicate of this bug. ***

Ill mark this bug as closed and kindly reopen if you still observe in 2.9.x or 2.8.1.1 or later. (Should be out in few hours)

*** Bug 362713 has been marked as a duplicate of this bug. ***

Sorry people, but I just had this crash once again on an evolution patched with Srinivasa's patch from comment #107. This time it took a week (usually I see this crash after a day or two) and also today my caching nameserver happened to be down, so I guess the timings could be differnt from the usual ones. Anyway, the backtrace looks just as it always does (full thread dump attached). 

The interesting parts:

(gdb) bt

+ Trace 76833

1223                    return;
1224
1225            for (p = priv->component_views; p != NULL; p = p->next) {
1226                    ComponentView *this_view = p->data;
1227
1228                    if (strcmp (this_view->component_id, component_id) == 0
1229                        || (this_view->component_alias != NULL
1230                            && strcmp (this_view->component_alias, component_id) == 0)) {
1231                            view = p->data;
1232                            break;
(gdb) print component_id
$1 = 0x64f380 "mail"
(gdb) print this_view->component_id
$2 = 0x0



Caveat: Just to make things more interesting, the version of evolution I've patched is evolution-2.6.3-1.fc5.5 from Fedora Core 5...

Created attachment 74886 [details]
back trace

*** Bug 363120 has been marked as a duplicate of this bug. ***

*** Bug 363137 has been marked as a duplicate of this bug. ***

*** Bug 363489 has been marked as a duplicate of this bug. ***

srini committed his patch at 2006-10-13.
duplicate bug 363489 states:
        Distribution: Gentoo Base System version 1.12.5
        Gnome Release: 2.16.1 2006-10-16 (Gentoo)
        BugBuddy Version: 2.16.0
would be interesting to know how up-to-date the gentoo packages are... daniel?

*** Bug 363329 has been marked as a duplicate of this bug. ***

*** Bug 362039 has been marked as a duplicate of this bug. ***

Current stable (2.14) is:
evolution 2.6.2
e-d-s 1.6.2
exchange 2.6.2

Current unstable (2.16) is:
evolution 2.8.1 + filter-bar crash fixer that went into 2.8.1.1
e-d-s 1.8.1
exchange 2.8.1

Should be fairly up-to-date.  I'm rolling 2.8.1.1 today.

Daniel, If this crash happens, can you get the traces of priv variable in gdb. That would be great interest to me, if this is happening again. Is Exchange plugin enable/installed in that machine? This can also help me fix the issue, if it is not really fixed. 

If I encounter someone with the crash, I'll try and walk them through it.  I've never personally see the crash, and I'm on 2.9.1 now, so it seems unlikely I'll see it.

*** Bug 364760 has been marked as a duplicate of this bug. ***

*** Bug 365310 has been marked as a duplicate of this bug. ***

*** Bug 364508 has been marked as a duplicate of this bug. ***

*** Bug 364445 has been marked as a duplicate of this bug. ***

*** Bug 366527 has been marked as a duplicate of this bug. ***

*** Bug 368256 has been marked as a duplicate of this bug. ***

*** Bug 369295 has been marked as a duplicate of this bug. ***

*** Bug 369114 has been marked as a duplicate of this bug. ***

*** Bug 371446 has been marked as a duplicate of this bug. ***

*** Bug 374354 has been marked as a duplicate of this bug. ***

*** Bug 375148 has been marked as a duplicate of this bug. ***

*** Bug 374985 has been marked as a duplicate of this bug. ***

*** Bug 374875 has been marked as a duplicate of this bug. ***

*** Bug 376651 has been marked as a duplicate of this bug. ***

*** Bug 376933 has been marked as a duplicate of this bug. ***

*** Bug 377783 has been marked as a duplicate of this bug. ***

*** Bug 378629 has been marked as a duplicate of this bug. ***

*** Bug 380382 has been marked as a duplicate of this bug. ***

*** Bug 380526 has been marked as a duplicate of this bug. ***

*** Bug 380998 has been marked as a duplicate of this bug. ***

*** Bug 381870 has been marked as a duplicate of this bug. ***

Reopening this bug as I am able to observe this consistently now.

Assigning this to myself. Working on this now.

Probably it's better to consider this patch:

http://bugzilla.gnome.org/attachment.cgi?id=74363

Although I am sure the reason is somewhere in the different place. We don't ref shell or drop ref eariler than required.

Harish: and please remove dirty srini hack.

*** Bug 383392 has been marked as a duplicate of this bug. ***

*** Bug 383901 has been marked as a duplicate of this bug. ***

*** Bug 383849 has been marked as a duplicate of this bug. ***

*** Bug 362015 has been marked as a duplicate of this bug. ***

*** Bug 384658 has been marked as a duplicate of this bug. ***

*** Bug 385659 has been marked as a duplicate of this bug. ***

*** Bug 384986 has been marked as a duplicate of this bug. ***

*** Bug 386778 has been marked as a duplicate of this bug. ***

*** Bug 386534 has been marked as a duplicate of this bug. ***

*** Bug 384667 has been marked as a duplicate of this bug. ***

*** Bug 390432 has been marked as a duplicate of this bug. ***

*** Bug 390623 has been marked as a duplicate of this bug. ***

*** Bug 390862 has been marked as a duplicate of this bug. ***

*** Bug 391170 has been marked as a duplicate of this bug. ***

*** Bug 391752 has been marked as a duplicate of this bug. ***

*** Bug 392705 has been marked as a duplicate of this bug. ***

*** Bug 392814 has been marked as a duplicate of this bug. ***

#392797 has a related stack trace

*** Bug 390293 has been marked as a duplicate of this bug. ***

*** Bug 393052 has been marked as a duplicate of this bug. ***

*** Bug 393569 has been marked as a duplicate of this bug. ***

*** Bug 393524 has been marked as a duplicate of this bug. ***

*** Bug 392797 has been marked as a duplicate of this bug. ***

*** Bug 377094 has been marked as a duplicate of this bug. ***

*** Bug 393797 has been marked as a duplicate of this bug. ***

*** Bug 393793 has been marked as a duplicate of this bug. ***

*** Bug 394195 has been marked as a duplicate of this bug. ***

*** Bug 394496 has been marked as a duplicate of this bug. ***

*** Bug 394447 has been marked as a duplicate of this bug. ***

*** Bug 393447 has been marked as a duplicate of this bug. ***

*** Bug 394689 has been marked as a duplicate of this bug. ***

*** Bug 394714 has been marked as a duplicate of this bug. ***

*** Bug 395000 has been marked as a duplicate of this bug. ***

*** Bug 395736 has been marked as a duplicate of this bug. ***

*** Bug 396099 has been marked as a duplicate of this bug. ***

*** Bug 396423 has been marked as a duplicate of this bug. ***

*** Bug 397440 has been marked as a duplicate of this bug. ***

*** Bug 398834 has been marked as a duplicate of this bug. ***

Hi guys...I had a good look into the trace and the associated code and here is what I found :

1. We still don't have a reliable set of steps to reproduce this crasher. I have not been able to reproduce this w/ and w/o the patches submitted above.
2. The patch on Comment #66 misses a fix by two counts - it never gets called and actually attempts to make a EComponentView out of a MailComponent object and hence  this needs to reverted from the code.
3. The other two patches are common in assuming the cause to be the set_title logic being triggered _after_ the shell-window or the component_view is destroyed. However, it seems to be very unlikely that at any given point, this_view remains valid but this_view->component_id is NULL. (See Comment #22).
4. I have a couple of weak hypotheses (weak as I have not been able simulate the crash even by artificial means by reducing the timeout interval and increasing the frequency of the set_title calls while closing down.

a. query_components in e-component-registry.c:146 can potentially generate the component_info structure with the id set to NULL which can trickle down to the shell-window's component_views to have nodes with component_id set to NULL while the overall structure remains valid. But this too is unlikely not to crash until the application is shutdown.

b. Random memory corruption - but valgrind sees nothing amiss thus far.

Also, the mail-component which provides the CORBA reference to the component view has no way to get notified if the component view is destroyed in shell.

Defensive programming by wrapping it with checks is one option - but I would not want to close it w/o getting at least one instance where it crashes repeatedly and the proposed fix addresses the issue.

We have accumulated a lot of crashers here...i still would like to call for anybody who can give me some more leads on this issue.

*** Bug 396989 has been marked as a duplicate of this bug. ***

*** Bug 399531 has been marked as a duplicate of this bug. ***

*** Bug 399524 has been marked as a duplicate of this bug. ***

*** Bug 399939 has been marked as a duplicate of this bug. ***

*** Bug 399944 has been marked as a duplicate of this bug. ***

(In reply to comment #8)
> Comment from https://launchpad.net/distros/ubuntu/+source/evolution/+bug/42411
> which is about that too:
> 
> "It crashes when I close it. But only when I have enabled "Empty Trash Folders
> on Exit [Every Time]", so it must be happening when it empties the trash."
> 

Yes, evolution crashes for me sometimes since I have enabled this option :-/

I will compile it with other cflags for trying to generate a more useful backtrace (http://www.gentoo.org/proj/en/qa/backtraces.xml)

Thanks

*** Bug 401753 has been marked as a duplicate of this bug. ***

*** Bug 403681 has been marked as a duplicate of this bug. ***

*** Bug 404423 has been marked as a duplicate of this bug. ***

*** Bug 405297 has been marked as a duplicate of this bug. ***

*** Bug 404603 has been marked as a duplicate of this bug. ***

*** Bug 405476 has been marked as a duplicate of this bug. ***

*** Bug 405569 has been marked as a duplicate of this bug. ***

*** Bug 405104 has been marked as a duplicate of this bug. ***

*** Bug 405733 has been marked as a duplicate of this bug. ***

*** Bug 406157 has been marked as a duplicate of this bug. ***

*** Bug 406601 has been marked as a duplicate of this bug. ***

*** Bug 406986 has been marked as a duplicate of this bug. ***

*** Bug 407874 has been marked as a duplicate of this bug. ***

*** Bug 407703 has been marked as a duplicate of this bug. ***

*** Bug 402519 has been marked as a duplicate of this bug. ***

*** Bug 402287 has been marked as a duplicate of this bug. ***

*** Bug 407280 has been marked as a duplicate of this bug. ***

*** Bug 408638 has been marked as a duplicate of this bug. ***

*** Bug 409109 has been marked as a duplicate of this bug. ***

*** Bug 409309 has been marked as a duplicate of this bug. ***

*** Bug 409810 has been marked as a duplicate of this bug. ***

*** Bug 410137 has been marked as a duplicate of this bug. ***

A quick checklist for other reporters
1. empty trash on exit every time?
2. debian sid?
3. amd64?
4. quick close after startup?
5. IMAP?
6. SSL?
7. Exchange enable?

1. I've also enable empty trash on exit every time.
2,3. I'm using evolution 2.6.3-4 on debian sid for amd64 installed with apt-get. I do have evolution and evolution-dbg installed.
4. I closed evolution very quickly after it started. (Reported as Bug 410137)
5,6. I'm using a SSL encrypted IMAP account.
7. No exchange or groupwise, but all other plugins are enabled

A quick checklist for other reporters

1. empty trash on exit every time?
Yes

2. debian sid?
Fedora Core 7

3. amd64?
i386/Intel Duo Core 

4. quick close after startup?
evolution closed after few hours of run

5. IMAP?
Yes, 1impa and 3pop3  account

6. SSL?
yes.

7. Exchange enable?
No. 

1. empty trash on exit every time?
When it crashed I had this enabled, yes. I've since turned it off and had no more crashes.
2. debian sid?
Gentoo
3. amd64?
Yes
4. quick close after startup?
Can honestly say I remember at this point.
5. IMAP?
No
6. SSL?
Yes
7. Exchange enable?
I don't know?

(In reply to comment #233)

> 1. empty trash on exit every time?
> 2. debian sid?
> 3. amd64?
> 4. quick close after startup?
> 5. IMAP?
> 6. SSL?
> 7. Exchange enable?
> 
1. I've also enable empty trash on exit every time.
2. evolution-2.8.3 on gentoo linux
3. amd64
4. No, I close it after some minutes
5. No
6. Yes
7. No

Thanks for fixing this

(In reply to comment #233)
> A quick checklist for other reporters
> 1. empty trash on exit every time?

Yes, I believe that is how I had it configured at the time.  It's now set to once per month, and I haven't had a crash in a while.

> 2. debian sid?

No.  Various Ubuntu versions (which I guess is quite close to sid).

> 3. amd64?

No.

> 4. quick close after startup?

No, I usually have it running all day.

> 5. IMAP?

Yes.

> 6. SSL?

Yes.

> 7. Exchange enable?

No.

Only question 1 and 6 true every time.

Could that mean that it's SSL related and related to "empty trash on exit every time"?

I would ask first - is it reproducable with 2.9?

I would ask: is anyone but devs using 2.9 on real email?

That said, I use 2.9.x for my primary email, and it's not repoducible here.  I have 2.9.91 right now, on amd64, with IMAP, SSL, and empty trash on exit every time.

I also unchecked "empty trash on exit" several days ago and don't have any crash since.

(In reply to comment #233)

> 1. empty trash on exit every time?
Yes

> 2. debian sid?
Fedora devel (evolution-2.9.5-4.fc7.x86_64), freezing for Fedora 7 now

> 3. amd64?
Yes

> 4. quick close after startup?
Sometimes

> 5. IMAP?
Yes

> 6. SSL?
Yes

> 7. Exchange enable?
No

(In reply to comment #240)
> I would ask: is anyone but devs using 2.9 on real email?
Yes

Well, Nicolas, can you please try the patch: 

http://bugzilla.gnome.org/attachment.cgi?id=74363

setting version as per comment #242.
unfortunately i have never been able to reproduce this. :-(

*** Bug 412489 has been marked as a duplicate of this bug. ***

*** Bug 413233 has been marked as a duplicate of this bug. ***

*** Bug 413530 has been marked as a duplicate of this bug. ***

*** Bug 413237 has been marked as a duplicate of this bug. ***

I have experienced this bug.

Some Info from My side:

a) I seem to have a serious problem with my Hardware (linux complains about NMIs on bootup, and the System randomly locks up / reboots. This seems to be related 
to the chipset, or something on the PCI bus. but i'm looking forward to a 
complete system upgrade, so i will not replace the faulty hardware.)

having that said, during this evolution crash, there was only one NMI at bootup, and the PC did not crash.

But there was something else that remarkable:

I'm using an Router (NAT hardware box) to get Online. My ISP seems to have some trouble, meaning that the PPPoE connection crashes very often. A particular PPPoE
session "lives" somwhere between 30s - 30m on my box. As soon as the connection crashes, my router tries to reconnect. But it's sometimes up to 5 minutes till a new connection is established.

I am using Imap (I want to access my emails from my PC @ work, and from @ home)

When this bug striked me, The following has happened:

a) I was checking out my emails by Imap.
b) Internet connection crashed (I verified this w/ firefox)
   => My Computer had no means to detect the state of the internet connection, 
   as this is handled by my router ...
c) being pissed off, i tried to close evolution
d) evolution crashed.


hope this helps ...

Harish, I'm slightly confused by comment 162 and comment 204. Can you or can you not reproduce this? Could you before, and what changed since?

Regarding the current state of this bug:  Usually it is considered prudent to ask for specific information, rather than just "more input" when setting to NEEDINFO.


Summary of the answers to the questions in comment 233:

 1) Empty Trash on Exit:  6/6
 3) AMD64                 4/6
 5) IMAP                  4/6
 6) SSL                   6/6

Exchange plugin is disabled for at least 5 reporters (1 don't know). Quick closing after starting Evo can positively be denied by at least 3 reporters.

It is rather striking that using SSL and a (non-default) setting to Empty Thrash on Exit matches for everyone who responded sonce comment 233 so far. Even more so, there are 3 reports stating, that disabling this resulted in not getting the crash since.

As far as the CPU architecture is concerned, there are 4 reports on AMD 64, 1 on Intel Duo Core, 1 unknown.  There are reports for 2.6.x, 2.8.x and 2.9.x at least.  Distro independent (FC 7, Debian Sid, Gentoo).


(The reported hardware seems to be rather new. However, this fact, just as the SSL fact /may/ possibly be just a red-herring, considering that fast, frequent and detailed responses are more common for people who are into this stuff itself. This part of the quick survey may be biased, but also possibly may be common ground.)

(In reply to comment #243)
> Well, Nicolas, can you please try the patch: 
> 
> http://bugzilla.gnome.org/attachment.cgi?id=74363
> 

Will it apply on evolution-2.9.92-1.fc7.x86_64 ? My evo got updated this week (it still crashes and not only after a quick start/close sequence)

Just to mention:

i can NOT reproduce this bug (fortunately ... :P )

*** Bug 414285 has been marked as a duplicate of this bug. ***

*** Bug 414312 has been marked as a duplicate of this bug. ***

*** Bug 414366 has been marked as a duplicate of this bug. ***

(In reply to comment #243)
> Well, Nicolas, can you please try the patch: 
> 
> http://bugzilla.gnome.org/attachment.cgi?id=74363

There:

Distribution: Fedora release 6.91 (Rawhide)
Gnome Release: 2.17.92 2007-02-27 (Red Hat, Inc)
BugBuddy Version: 2.17.4

System: Linux 2.6.21-0.7.rc2.mm1.fc7 #1 SMP Sat Mar 3 17:20:02 CET 2007 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 70200000
Selinux: No
Accessibility: Enabled
GTK+ Theme: Clearlooks
Icon Theme: Bluecurve

Memory status: size: 572919808 vsize: 572919808 resident: 48095232 share: 18092032 rss: 48095232 rss_rlim: 18446744073709551615
CPU usage: start_time: 1173014444 rtime: 2630 utime: 2307 stime: 323 cutime:37 cstime: 25 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47315548831376 (LWP 15377)]
[New Thread 1090525504 (LWP 16017)]
[New Thread 1099184448 (LWP 15418)]
0x0000003234e0d83f in __libc_waitpid (pid=16020, stat_loc=0x7fff2833049c, 
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41
41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);

+ Trace 115763

0x0000003234e0d83f	41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


----------- .xsession-errors (15 sec old) ---------------------
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
GTK Accessibility Module initialized
Bonobo accessibility support initialized
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
GTK Accessibility Module initialized
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Bonobo accessibility support initialized
--------------------------------------------------

Another dump for patched evo with more debuginfo on system (looks I'm still missing a glibc bit though)

Distribution: Fedora release 6.91 (Rawhide)
Gnome Release: 2.17.92 2007-02-27 (Red Hat, Inc)
BugBuddy Version: 2.17.4

System: Linux 2.6.21-0.7.rc2.mm1.fc7 #1 SMP Sat Mar 3 17:20:02 CET 2007 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 70200000
Selinux: No
Accessibility: Enabled
GTK+ Theme: Clearlooks
Icon Theme: Bluecurve

Memory status: size: 684924928 vsize: 684924928 resident: 51265536 share: 20979712 rss: 51265536 rss_rlim: 18446744073709551615
CPU usage: start_time: 1173033557 rtime: 2557 utime: 2233 stime: 324 cutime:23 cstime: 20 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47272246742672 (LWP 17579)]
[New Thread 1107310912 (LWP 18524)]
[New Thread 1082132800 (LWP 18344)]
[New Thread 1090791744 (LWP 18152)]
0x0000003234e0d83f in __libc_waitpid (pid=18527, stat_loc=0x7fff3d3495bc, 
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41
41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);

+ Trace 115832

0x0000003234e0d83f	41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


----------- .xsession-errors (15 sec old) ---------------------
(gnome-terminal:18481): Vte-WARNING **: Can not find appropiate font for character U+ac01.
(gnome-terminal:18481): Vte-WARNING **: Can not find appropiate font for character U+ac04.
(gnome-terminal:18481): Vte-WARNING **: Can not find appropiate font for character U+ac08.
(gnome-terminal:18481): Vte-WARNING **: Can not find appropiate font for character U+ac10.
GTK Accessibility Module initialized
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Bonobo accessibility support initialized
--------------------------------------------------

(In reply to comment #250)
> Harish, I'm slightly confused by comment 162 and comment 204. Can you or can
> you not reproduce this? Could you before, and what changed since?
 
Yes - I could once observe on my machine by starting evolution and closing it immediately. And later when the trunk moved in time - it is not reproducible anymore.

> Regarding the current state of this bug:  Usually it is considered prudent to
> ask for specific information, rather than just "more input" when setting to
> NEEDINFO.
For what my prudence is worth - I had asked if there are any reliable steps that can help me reproduce the issue and many were kind enough to offer help but I do not have anything that helps me observe the issue or assess the fix.

I have no clue what else to ask - let us know if you do.


> 
> Summary of the answers to the questions in comment 233:
> 
>  1) Empty Trash on Exit:  6/6
>  3) AMD64                 4/6
>  5) IMAP                  4/6
>  6) SSL                   6/6
> 
> Exchange plugin is disabled for at least 5 reporters (1 don't know). Quick
> closing after starting Evo can positively be denied by at least 3 reporters.
> 
> It is rather striking that using SSL and a (non-default) setting to Empty
> Thrash on Exit matches for everyone who responded sonce comment 233 so far.
> Even more so, there are 3 reports stating, that disabling this resulted in not
> getting the crash since.
> 
> As far as the CPU architecture is concerned, there are 4 reports on AMD 64, 1
> on Intel Duo Core, 1 unknown.  There are reports for 2.6.x, 2.8.x and 2.9.x at
> least.  Distro independent (FC 7, Debian Sid, Gentoo).
> 
> 
> (The reported hardware seems to be rather new. However, this fact, just as the
> SSL fact /may/ possibly be just a red-herring, considering that fast, frequent
> and detailed responses are more common for people who are into this stuff
> itself. This part of the quick survey may be biased, but also possibly may be
> common ground.)
> 
Nice stats..Also, there are other users who have not been able to observe this bug at all.

Btw, I can see at least two different issues here - 
1. the camel_shutdown stack [Comment #27, Comment #257 - ]
2. the shell_window_set_title [ I posted what I understood from the code on Comment #204 ].


Maybe this bug needs fresh eyeballs. Others ?

Another one :

Distribution: Fedora release 6.91 (Rawhide)
Gnome Release: 2.17.92 2007-02-27 (Red Hat, Inc)
BugBuddy Version: 2.17.4

System: Linux 2.6.21-0.8.rc2.mm1.fc7 #1 SMP Mon Mar 5 21:28:34 CET 2007 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 70200000
Selinux: No
Accessibility: Enabled
GTK+ Theme: Clearlooks
Icon Theme: Bluecurve

Memory status: size: 692830208 vsize: 692830208 resident: 56172544 share: 21049344 rss: 56172544 rss_rlim: 18446744073709551615
CPU usage: start_time: 1173163566 rtime: 3111 utime: 2701 stime: 410 cutime:88 cstime: 41 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47840226512528 (LWP 6743)]
[New Thread 1124096320 (LWP 7082)]
[New Thread 1099184448 (LWP 6933)]
[New Thread 1082132800 (LWP 6931)]
0x0000003234e0d83f in __libc_waitpid (pid=7085, stat_loc=0x7ffffef900fc, 
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41
41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);

+ Trace 116231

0x0000003234e0d83f	41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
The program is running.  Quit anyway (and detach it)? (y or n) [answered Y; input not from terminal]


----------- .xsession-errors (18 sec old) ---------------------
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
GTK Accessibility Module initialized
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Bonobo accessibility support initialized
--------------------------------------------------

*** Bug 415047 has been marked as a duplicate of this bug. ***

I got the same problem that sometimes Evolution crash when I tried to close it.  When I close the application I got a dialog box with an error message.  The error report can be found in http://bugzilla.gnome.org/show_bug.cgi?id=415047.  If I re-start Evolution and then close it again, I don't get the error message.

*** Bug 415805 has been marked as a duplicate of this bug. ***

*** Bug 416398 has been marked as a duplicate of this bug. ***

*** Bug 416538 has been marked as a duplicate of this bug. ***

*** Bug 415691 has been marked as a duplicate of this bug. ***

*** Bug 416015 has been marked as a duplicate of this bug. ***

*** Bug 418089 has been marked as a duplicate of this bug. ***

And with evo 2.10, still crashing on close (evolution-2.10.0-2.fc7.x86_64)

Distribution: Fedora release 6.91 (Rawhide)
Gnome Release: 2.18.0 2007-03-13 (Red Hat, Inc)
BugBuddy Version: 2.18.0

System: Linux 2.6.21-0.22.rc3.mm2.rsdl031.fc7 #1 SMP Fri Mar 16 19:02:01 CET 2007 x86_64
X Vendor: The X.Org Foundation
X Vendor Release: 10299901
Selinux: No
Accessibility: Enabled
GTK+ Theme: Clearlooks
Icon Theme: Bluecurve

Memory status: size: 707616768 vsize: 707616768 resident: 57434112 share: 24055808 rss: 57434112 rss_rlim: 18446744073709551615
CPU usage: start_time: 1174070303 rtime: 3489 utime: 3039 stime: 450 cutime:30 cstime: 33 timeout: 0 it_real_value: 0 frequency: 100

Backtrace was generated from '/usr/bin/evolution'

Using host libthread_db library "/lib64/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 47493511464368 (LWP 3396)]
[New Thread 1115703616 (LWP 4231)]
[New Thread 1074006336 (LWP 3944)]
0x0000003234e0d83f in __libc_waitpid (pid=4933, stat_loc=0x7fffb94f21fc, 
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:41
41	  int result = INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);

+ Trace 119251

----------- .xsession-errors (24 sec old) ---------------------
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
 Header string finally is ********** 
HEADER.FIELDS (DATE FROM TO CC SUBJECT REFERENCES IN-REPLY-TO MESSAGE-ID MIME-VERSION CONTENT-TYPE X-MAILING-LIST X-LOOP LIST-ID LIST-POST MAILING-LIST ORIGINATOR X-LIST SENDER RETURN-PATH X-BEENTHERE
process 3396: The last reference on a connection was dropped without closing the connection. This is a bug in an application. See dbus_connection_unref() documentation for details.
Most likely, the application was supposed to call dbus_connection_close(), since this is a private connection.
  D-Bus not built with -rdynamic so unable to print a backtrace
GTK Accessibility Module initialized
Bonobo accessibility support initialized
GTK Accessibility Module initialized
Bonobo accessibility support initialized
--------------------------------------------------

No, Nicolas, your stacktrace shows you've met completely different bug 405646, this problem is about set_title crash, not about every crash on exit.

P.S. Sorry for spamming

*** Bug 420572 has been marked as a duplicate of this bug. ***

*** Bug 420621 has been marked as a duplicate of this bug. ***

*** Bug 419984 has been marked as a duplicate of this bug. ***

*** Bug 420023 has been marked as a duplicate of this bug. ***

*** Bug 420094 has been marked as a duplicate of this bug. ***

*** Bug 421000 has been marked as a duplicate of this bug. ***

*** Bug 424155 has been marked as a duplicate of this bug. ***

*** Bug 425332 has been marked as a duplicate of this bug. ***

*** Bug 425323 has been marked as a duplicate of this bug. ***

*** Bug 423557 has been marked as a duplicate of this bug. ***

*** Bug 424323 has been marked as a duplicate of this bug. ***

*** Bug 424333 has been marked as a duplicate of this bug. ***

*** Bug 425577 has been marked as a duplicate of this bug. ***

*** Bug 423525 has been marked as a duplicate of this bug. ***

*** Bug 426055 has been marked as a duplicate of this bug. ***

*** Bug 427677 has been marked as a duplicate of this bug. ***

*** Bug 415290 has been marked as a duplicate of this bug. ***

*** Bug 427033 has been marked as a duplicate of this bug. ***

*** Bug 428288 has been marked as a duplicate of this bug. ***

bug #428288 which just has been marked a dupe is evo 2.10.1 BTW (evolution-2.10.1-1.fc7.x86_64)

Why is this bug marked as needinfo? The questions asked were answered, right?

because of comment #204 i guess

Then, I don't know if it could help, but I will explain my situation:

I have installed evolution and evolution-data-server 1.8.3, the crashes started after enabling  "empty trash on exit" option. I usually open evolution, read my emails and mark as spam and remove some of theme, later, I leave evolution opened for one or two hours, then, I close it and (usually) crashes.

Thanks a lot

*** Bug 428670 has been marked as a duplicate of this bug. ***

*** Bug 428796 has been marked as a duplicate of this bug. ***

*** Bug 428721 has been marked as a duplicate of this bug. ***

(In reply to comment #233)
> A quick checklist for other reporters
> 1. empty trash on exit every time?

Yes.

> 2. debian sid?

No. Nowdays I'm using FC6: evolution-2.8.3-1.fc6

> 3. amd64?

i386.

> 4. quick close after startup?

Sometimes yes.

> 5. IMAP?

Yes. And POP3 also.

> 6. SSL?

Yes on both POP3 and IMAP.

> 7. Exchange enable?

No.

Anyway, I'd like to stress that I've _not_ ecountered this crash since I posted on comment #114.

*** Bug 429749 has been marked as a duplicate of this bug. ***

*** Bug 429963 has been marked as a duplicate of this bug. ***

*** Bug 430167 has been marked as a duplicate of this bug. ***

*** Bug 416340 has been marked as a duplicate of this bug. ***

*** Bug 431425 has been marked as a duplicate of this bug. ***

*** Bug 433293 has been marked as a duplicate of this bug. ***

*** Bug 434552 has been marked as a duplicate of this bug. ***

*** Bug 435244 has been marked as a duplicate of this bug. ***

*** Bug 435580 has been marked as a duplicate of this bug. ***

> Btw, I can see at least two different issues here - 
> 1. the camel_shutdown stack [Comment #27, Comment #257 - ]

#27 is a different bug altogether that was fixed already. 
#257 is with http://bugzilla.gnome.org/attachment.cgi?id=72161 which you have reviewed in comment #204 

> 2. the shell_window_set_title [ I posted what I understood from the code on
> Comment #204 ].
> 
> 
> Maybe this bug needs fresh eyeballs. Others ?
> 

the set_title issue is the real issue to be focussed here. 

The crash happens becoz this_view->component_id is null. In the entire code, this can happen only when in finalize method the views are freed which would invalidate the views that set_title is handling.

With my patch, before beginning dispose method, I mark the object for destroy which is checked before setting the title. So it avoids the crash most probably. 

But it still can happen if the condition (if-destroyed) is passed and after that in a different thread the views structure gets freed. But that is very rare but can potentially happen. 

I was able to reproduce the bug more reliably when I commented the two lines in below code (My previous patch). It reduces the probability of the crash.

shell/e-shell-window.c:

void
e_shell_window_set_title(EShellWindow *window, const char *component_id, const char *title)
{
	EShellWindowPrivate *priv = window->priv;
	ComponentView *view = NULL;
	GSList *p;

/* 	if (priv->destroyed) */
/* 		return; */


All these happen in a single thread. So it can't be locked. The approach can also be take the patch http://bugzilla.gnome.org/attachment.cgi?id=72161 and fix it to do remove the timeout on impl_quit or other right place and fix the object to component_view

Also, another way to "avoid the crash" is by employing a safe strcmp so that null doesn't crash. Even if it is junk/crap it wont enter set the view. But that is never a soln. 


I prefer to fix in shell and if no way it works then take the patch http://bugzilla.gnome.org/attachment.cgi?id=72161 and fix it. I definitely dont want to take the last one.

I should have some fix for this in 2.11.2.

By "Last one", I mean the "avoid to crash" soln. Sorry for the confusion.

*** Bug 433497 has been marked as a duplicate of this bug. ***

Created attachment 87935 [details] [review]
Proposed patch

This should fix the bug. On quit, never try to set the title. I have moved the fix from shell to mail. This will obsolete my earlier patch as well as Nickolay's patch.

Created attachment 87977 [details]
Crash dump

Crash on Fedora Devel (soon to be Fedora 8) evolution-2.10.1-4.fc7.x86_64 + proposed attachment #87935 [details] patch

Trying to provide fresh eyeballs for this problem.

One thing I'm struggling to understand is whether we really need this timeout at all.  The following source code comment seems to provide the rationale:

        /* This can get called 3 times every cursor move, so
           we don't need to/want to run it immediately */

I guess my naive question is "who cares?"  Is there some particularly expensive logic being triggered in view_changed() that justifies this minor optimization and major headache?  I'll assume there is, though I'm not seeing it.

The chain of events as I understand it is something like:

   1) EMFolderView emits a "changed" or "loaded" signal, which triggers the
      view_changed_cb() handler in mail-component.c.

   2) EMFolderView apparently tends to fire these signals in clusters, but
      we don't want to handle each and every signal.  We want to handle the
      cluster as a whole.

   3) To do this we defer the handling of the signal for a short interval
      by way of g_timeout_add().  During this interval we "suck up" any other
      "changed" or "loaded" signals by restarting the timer.

   4) Once the timer expires, we finally handle the signal.  Problem is the
      shutdown process may have been started in the interim, so objects we
      need are getting finalized.

Perhaps a better approach would be to -- instead of delaying the HANDLING of the signals for a short period of time -- delay the EMISSION of the signals for a short period of time.  So when the EMFolderView wants to emit one of these signals, instead of calling g_signal_emit() directly it could start a timer.  While the timer is running, "suck up" any other emissions of these signals the same way we do in view_changed_cb().  When the timer expires, emit ONE signal.  This would eliminate the cluster of signals that we're trying to work around in view_changed_cb().

With that in place, we could handle the signal directly in view_changed_cb() and elminate all the timer mechanics in mail-component.c.  If the shutdown process begins while the signal emission timer is running, we could simply disable the signal so that the timeout handler has no effect, thereby (I think) eliminating the source of the crash instead of trying to work around it.

I've only looked at the code briefly so I could very well be missing something important.  Does this alternate approach sound feasible?

Created attachment 87991 [details] [review]
Updated patch

I know it is a very silly typo. Sorry for the trouble.  Nicolas Mailhot  can you try this?

(In reply to comment #312)
> Trying to provide fresh eyeballs for this problem.
> 
> One thing I'm struggling to understand is whether we really need this timeout
> at all.  The following source code comment seems to provide the rationale:
> 
>         /* This can get called 3 times every cursor move, so
>            we don't need to/want to run it immediately */
> 
> I guess my naive question is "who cares?"  Is there some particularly expensive
> logic being triggered in view_changed() that justifies this minor optimization
> and major headache?  I'll assume there is, though I'm not seeing it.
> 
> The chain of events as I understand it is something like:
> 
>    1) EMFolderView emits a "changed" or "loaded" signal, which triggers the
>       view_changed_cb() handler in mail-component.c.
> 
>    2) EMFolderView apparently tends to fire these signals in clusters, but
>       we don't want to handle each and every signal.  We want to handle the
>       cluster as a whole.
> 
>    3) To do this we defer the handling of the signal for a short interval
>       by way of g_timeout_add().  During this interval we "suck up" any other
>       "changed" or "loaded" signals by restarting the timer.
> 
>    4) Once the timer expires, we finally handle the signal.  Problem is the
>       shutdown process may have been started in the interim, so objects we
>       need are getting finalized.
> 

The problem varies here. What triggers this crash is that if you have "clear trash or junk on quit", you start the shutdown process and that goes on clearing trash or junk, then sync with the server, so the folder has changed, so view changed gets called and by the time it comes to view_changed things are already freed up. I don't see a clear improvement here. 

The better way I see is that if the shutdown has started don't handle the signal rather ignore it. Who cares if it doesn't update the info-label and title when I have already pressed File->Quit or 'X' button.


> Perhaps a better approach would be to -- instead of delaying the HANDLING of
> the signals for a short period of time -- delay the EMISSION of the signals for
> a short period of time.  So when the EMFolderView wants to emit one of these
> signals, instead of calling g_signal_emit() directly it could start a timer. 
> While the timer is running, "suck up" any other emissions of these signals the
> same way we do in view_changed_cb().  When the timer expires, emit ONE signal. 
> This would eliminate the cluster of signals that we're trying to work around in
> view_changed_cb().
> 
> With that in place, we could handle the signal directly in view_changed_cb()
> and elminate all the timer mechanics in mail-component.c.  If the shutdown
> process begins while the signal emission timer is running, we could simply
> disable the signal so that the timeout handler has no effect, thereby (I think)
> eliminating the source of the crash instead of trying to work around it.
> 
> I've only looked at the code briefly so I could very well be missing something
> important.  Does this alternate approach sound feasible?
> 

Ah, I see.  So the timer doesn't really factor into this at all.

Your solution make sense.  Thanks for the clarification.

Created attachment 88019 [details]
Crash trace

Crash on Fedora Devel (soon to be Fedora 7) evolution-2.10.1-4.fc7.x86_64 +
proposed attachment #87991 [details] patch

Took a bit more work than usual to crash evo

Nicholas, the traces seem to be different here. It shouldn't crash here after IMO. This crash may be becoz of something else not even related to this.. 

I should say a lots of thanks for testing the patch. I would wait till monday UTC 00:00 before I test this for 2.11.2. Let me know if you face any more issues.

Ive committed this for 2.11.2. I would keep the bug open for some more time, atleast till I push this for 2.10.2

(In reply to comment #318)
> Ive committed this for 2.11.2. I would keep the bug open for some more time,
> atleast till I push this for 2.10.2

Thanks a lot. No crash there since the one you said was something else

we ask anybody who runs an unstable (2.11.x) version of evolution and who was able to reproduce this crash to please test version 2.11.2 which includes a patch for this issue, and to please report here if this crash still happens.

thanks a lot in advance for your help!

*** Bug 438988 has been marked as a duplicate of this bug. ***

*** Bug 439370 has been marked as a duplicate of this bug. ***

Created attachment 88432 [details]
Shutdown error pop-up

I don't know whether my problem is the same as you guys are discussing, or if it's related to it, but I crash and get the attached pop-up every time I close Evolution. I'm running Evo-2.8.2-2 under Windows XP SP2.

*** Bug 439979 has been marked as a duplicate of this bug. ***

*** Bug 435072 has been marked as a duplicate of this bug. ***

Seems fine till now. Ill push this patch for 2.10.2

Fixed to stable 2.10.2.

*** Bug 441667 has been marked as a duplicate of this bug. ***

*** Bug 441838 has been marked as a duplicate of this bug. ***

*** Bug 442194 has been marked as a duplicate of this bug. ***

*** Bug 442609 has been marked as a duplicate of this bug. ***

*** Bug 443235 has been marked as a duplicate of this bug. ***

*** Bug 445476 has been marked as a duplicate of this bug. ***

*** Bug 445878 has been marked as a duplicate of this bug. ***

*** Bug 444210 has been marked as a duplicate of this bug. ***

*** Bug 446098 has been marked as a duplicate of this bug. ***

*** Bug 444874 has been marked as a duplicate of this bug. ***

*** Bug 445097 has been marked as a duplicate of this bug. ***

*** Bug 445642 has been marked as a duplicate of this bug. ***

*** Bug 445496 has been marked as a duplicate of this bug. ***

*** Bug 446130 has been marked as a duplicate of this bug. ***

*** Bug 445762 has been marked as a duplicate of this bug. ***

*** Bug 445685 has been marked as a duplicate of this bug. ***

*** Bug 445651 has been marked as a duplicate of this bug. ***

*** Bug 445519 has been marked as a duplicate of this bug. ***

*** Bug 446222 has been marked as a duplicate of this bug. ***

*** Bug 446839 has been marked as a duplicate of this bug. ***

*** Bug 446893 has been marked as a duplicate of this bug. ***

*** Bug 447492 has been marked as a duplicate of this bug. ***

*** Bug 447613 has been marked as a duplicate of this bug. ***

*** Bug 448578 has been marked as a duplicate of this bug. ***

*** Bug 449443 has been marked as a duplicate of this bug. ***

*** Bug 449502 has been marked as a duplicate of this bug. ***

*** Bug 434136 has been marked as a duplicate of this bug. ***

*** Bug 449823 has been marked as a duplicate of this bug. ***

*** Bug 449945 has been marked as a duplicate of this bug. ***

*** Bug 450062 has been marked as a duplicate of this bug. ***

*** Bug 451438 has been marked as a duplicate of this bug. ***

*** Bug 451978 has been marked as a duplicate of this bug. ***

*** Bug 452643 has been marked as a duplicate of this bug. ***

*** Bug 453355 has been marked as a duplicate of this bug. ***

*** Bug 447430 has been marked as a duplicate of this bug. ***

*** Bug 450787 has been marked as a duplicate of this bug. ***

*** Bug 455125 has been marked as a duplicate of this bug. ***

*** Bug 455644 has been marked as a duplicate of this bug. ***

*** Bug 453923 has been marked as a duplicate of this bug. ***

*** Bug 456274 has been marked as a duplicate of this bug. ***

*** Bug 457358 has been marked as a duplicate of this bug. ***

*** Bug 459020 has been marked as a duplicate of this bug. ***

*** Bug 456498 has been marked as a duplicate of this bug. ***

*** Bug 459389 has been marked as a duplicate of this bug. ***

*** Bug 459903 has been marked as a duplicate of this bug. ***

*** Bug 462199 has been marked as a duplicate of this bug. ***

*** Bug 462860 has been marked as a duplicate of this bug. ***

*** Bug 463518 has been marked as a duplicate of this bug. ***

*** Bug 464253 has been marked as a duplicate of this bug. ***

*** Bug 464448 has been marked as a duplicate of this bug. ***

*** Bug 466482 has been marked as a duplicate of this bug. ***

*** Bug 457900 has been marked as a duplicate of this bug. ***

*** Bug 465845 has been marked as a duplicate of this bug. ***

*** Bug 464724 has been marked as a duplicate of this bug. ***

*** Bug 468747 has been marked as a duplicate of this bug. ***

*** Bug 470157 has been marked as a duplicate of this bug. ***

*** Bug 472215 has been marked as a duplicate of this bug. ***

*** Bug 472235 has been marked as a duplicate of this bug. ***

*** Bug 472594 has been marked as a duplicate of this bug. ***

*** Bug 471421 has been marked as a duplicate of this bug. ***

*** Bug 474075 has been marked as a duplicate of this bug. ***

*** Bug 474768 has been marked as a duplicate of this bug. ***

*** Bug 474644 has been marked as a duplicate of this bug. ***

*** Bug 474397 has been marked as a duplicate of this bug. ***

*** Bug 475483 has been marked as a duplicate of this bug. ***

*** Bug 475881 has been marked as a duplicate of this bug. ***

*** Bug 476495 has been marked as a duplicate of this bug. ***

*** Bug 477103 has been marked as a duplicate of this bug. ***

*** Bug 477116 has been marked as a duplicate of this bug. ***

*** Bug 477469 has been marked as a duplicate of this bug. ***

*** Bug 479315 has been marked as a duplicate of this bug. ***

*** Bug 482657 has been marked as a duplicate of this bug. ***

*** Bug 480915 has been marked as a duplicate of this bug. ***

*** Bug 483236 has been marked as a duplicate of this bug. ***

*** Bug 496604 has been marked as a duplicate of this bug. ***

*** Bug 477293 has been marked as a duplicate of this bug. ***

*** Bug 480438 has been marked as a duplicate of this bug. ***

*** Bug 517240 has been marked as a duplicate of this bug. ***

*** Bug 518436 has been marked as a duplicate of this bug. ***

*** Bug 518471 has been marked as a duplicate of this bug. ***

*** Bug 520305 has been marked as a duplicate of this bug. ***

*** Bug 558301 has been marked as a duplicate of this bug. ***

*** Bug 437740 has been marked as a duplicate of this bug. ***

*** Bug 583186 has been marked as a duplicate of this bug. ***