After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 317785 - Evolution crashes weirdly
Evolution crashes weirdly
Status: RESOLVED DUPLICATE of bug 320772
Product: evolution
Classification: Applications
Component: Mailer
2.4.x (obsolete)
Other All
: High critical
: ---
Assigned To: Shreyas Srinivasan
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-10-03 02:50 UTC by Shreyas Srinivasan
Modified: 2005-11-21 08:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Description Shreyas Srinivasan 2005-10-03 02:50:28 UTC 
Steps to reproduce:
1. Open evolution
2. Close evolution before vfolder's sync up
3. Evolution crashes


Stack trace:

+ Trace 63328

  • #0 ??
  • #1 camel_object_trigger_event
    at camel-object.c line 1502
  • #2 vee_remove_folder
    at camel-vee-folder.c line 831
  • #3 camel_vee_folder_remove_folder
    at camel-vee-folder.c line 296
  • #4 camel_vee_folder_finalise
    at camel-vee-folder.c line 1723
  • #5 camel_object_unref
    at camel-object.c line 925
  • #6 vfolder_foreach_cb
    at mail-vfolder.c line 1178
  • #7 g_hash_table_foreach
  • #8 mail_vfolder_shutdown
    at mail-vfolder.c line 1188
  • #9 impl_quit
    at mail-component.c line 723
  • #10 _ORBIT_skel_small_GNOME_Evolution_Component_quit
    at Evolution-common.c line 32
  • #11 GNOME_Evolution_Component_quit
    at Evolution-stubs.c line 41
  • #12 es_run_quit
    at e-shell.c line 1293
  • #13 e_shell_quit
    at e-shell.c line 1361
  • #14 e_shell_request_close_window
    at e-shell.c line 962
  • #15 window_delete_event_cb
    at e-shell.c line 343
  • #16 _gtk_marshal_BOOLEAN__BOXED
  • #17 g_closure_invoke
  • #18 signal_emit_unlocked_R
  • #19 g_signal_emit_valist
  • #20 g_signal_emit
  • #21 gtk_widget_event_internal
  • #22 gtk_main_do_event
  • #23 gdk_event_dispatch
  • #24 g_main_dispatch
  • #25 g_main_context_iterate
  • #26 g_main_loop_run
  • #27 bonobo_main
  • #28 main
    at main.c line 602 


Other information:
mostly not reproducible but the stack space shows some interesting information.
Comment 1 Shreyas Srinivasan 2005-10-03 02:51:33 UTC 



+
Trace
    63329






    

  • 
#1
camel_object_trigger_event

    
                at camel-object.c
                  line
                  1502

    

    • 







1497
1498                    /* now execute the events we have, if they haven't been
removed during our calls */
1499                    for (i=size-1;i>=0;i--) {
1500                            pair = pairs[i];
1501                            if ((pair->flags & CAMEL_HOOK_PAIR_REMOVED) == 0)
1502                                    (pair->func.event) (obj, event_data,
pair->data);
1503                    }
1504                    hooks->depth--;
1505
1506                    /* and if we're out of any events, then clean up any
pending removes */
(gdb) 








Comment 2


Shreyas Srinivasan





          2005-10-03 02:53:02 UTC
        






+
Trace
    63330






    

  • 
#2
vee_remove_folder

    
                at camel-vee-folder.c
                  line
                  831

    

    • 







826                     camel_object_trigger_event((CamelObject
*)folder_unmatched, "folder_changed", unmatched_changes);
827                     camel_folder_change_info_free(unmatched_changes);
828             }
829
830             if (vf_changes) {
831                     camel_object_trigger_event((CamelObject *)vf,
"folder_changed", vf_changes);
832                     camel_folder_change_info_free(vf_changes);
833             }
834     }
835







Comment 3


Shreyas Srinivasan





          2005-10-03 03:08:43 UTC
        



Hmm.. Super cool crash. So the static string "folder_changed" being sent as a
signal name is losing memory by the time the callee gets control. Hmm.. there
was a patch which NotZed gave on camel-object-bag.diff which fixed these
assertions. Wonder is they ever saw the light






Comment 4


Shreyas Srinivasan





          2005-10-03 03:12:14 UTC
        



Yup, those patches did get into cvs. Just looks like one of the problems not
addressed in that patch. Assigning to myself






Comment 5


André Klapper





          2005-11-20 23:24:19 UTC
        



shres: stacktrace partially matching with bug 320772, do you think this is fixed?






Comment 6


Shreyas Srinivasan





          2005-11-21 08:14:21 UTC
        



Cant reproduce it anymore, it was happenning rarely anyway. The stack looks
pretty similar. Closing as duplicate for now until it comes back to bite me later.

*** This bug has been marked as a duplicate of 320772 ***