GNOME Bugzilla – Bug 617930
Crash under mail_sidebar_model_loaded_row_cb
Last modified: 2012-03-28 17:28:10 UTC
Using gnome-2-30 in fact:
+ Trace 221774
Thread 1 (Thread 5605)
Just got another of these:
+ Trace 221969
Thread 1 (Thread 9893)
And another one of these on gnome-2-30:
+ Trace 223123
Thread 1 (Thread 10160)
*** Bug 627404 has been marked as a duplicate of this bug. ***
Looks like I got another one of these using gnome-2-30 f3faa077093912674aacf91905136375f03a44d2 and ff3413b5cd96b3f490b760e4c7160ac64cbff7c6:
+ Trace 223537
Thread 1 (Thread 18632)
*** Bug 621488 has been marked as a duplicate of this bug. ***
OK, so it tried to read the "Expanded" state from a key file and it failed there for some reason. Do you see any runtime warnings on console when this happens, please? Also, could you run evolution as follows, to see whether there happened something wrong with memory management, please? $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>evo.log Thanks in advance.
(In reply to comment #6) > > Also, could you run evolution as follows, to see whether there happened > something wrong with memory management, please? > $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>evo.log No. Running evolution under valgrind makes it _completely_ unusable. It takes 10s of minutes just to start up and every operation after that takes many minutes. I don't have hours to just sit here idly watching and interacting with a slower-than-molasses evolution. I use evolution during my day-job and spending hours doing this kind of testing severely impacts my day-job productivity. Sorry I cannot be more helpful.
No problem, evo is awfully slow when running under valgrind with search folders enabled, that's right. You can try to run evolution with that G_SLICE only, maybe glib's memory error detector will spot something: $ G_SLICE=always-malloc evolution
*** Bug 634223 has been marked as a duplicate of this bug. ***
Downstream bug report about the same in 2.32.0: https://bugzilla.redhat.com/show_bug.cgi?id=644006
+ Trace 224587
Thread 1 (Thread 2925)
*** Bug 638646 has been marked as a duplicate of this bug. ***
*** Bug 644065 has been marked as a duplicate of this bug. ***
Steps from Bug 644065 What were you doing when the application crashed? 1. Create a rule on mailinglist (from right-click context menu) 2. Rule action is to move to folder. 3. Specify the folder as a new folder under root node (On This Computer) 4. Ok -> crash
Works for me with 2.91.91, no crash and valgrind doesn't claim anything too.
*** Bug 644948 has been marked as a duplicate of this bug. ***
*** Bug 648165 has been marked as a duplicate of this bug. ***
*** Bug 644091 has been marked as a duplicate of this bug. ***
Downstream bug report from 3.0.1: https://bugzilla.redhat.com/show_bug.cgi?id=706401
While looking on another downstream duplicate of this, form 3.2.x this time: https://bugzilla.redhat.com/show_bug.cgi?id=741171 I think I found what is causing this. I can reproduce something similar with these steps: a) run evolution in mailer: $ evolution -c mail b) choose File->New Window c) close this new window of mailer d) in the first window choose Edit->Preferences->Mail Accounts and enable a new account (or expand account node which wasn't loaded yet Poof, evolution crashes. (not for me, though, but I get runtime warnings indicating the issue).
Created attachment 210797 [details] [review] evo patch for evolution; The change is pretty simple, after all. The EMailSidebar is using global folder tree model, and connects to it this mail_sidebar_model_loaded_row_cb() function, but never disconnect, though following my steps above result in freed EMailSidebar, with left signal connection on it in the model. That's basically causing trouble here. Knowing this is caused by opening new mail windows I believe it would be fixed much sooner.
Created commit c17965f in evo master (3.5.1+) Created commit 936a488 in evo gnome-3-4 (3.4.1+)