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 326327 - Evolution Crashed on Task creation
Evolution Crashed on Task creation
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Tasks
2.6.x (obsolete)
Other Mac OS
: Normal normal
: ---
Assigned To: Shreyas Srinivasan
Evolution QA team
Depends on:
Blocks: 327508 327510
 
 
Reported: 2006-01-09 17:42 UTC by Shreyas Srinivasan
Modified: 2013-09-13 00:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Shreyas Srinivasan 2006-01-09 17:42:06 UTC
Just double clicked on new task button and evolution crashed. 

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000027
0x028e99c4 in g_type_check_instance_cast ()

Thread 7 (process 8254 thread 0x3503)

  • #0 semaphore_wait_signal_trap
  • #1 pthread_cond_wait
  • #2 e_msgport_wait
    at e-msgport.c line 660
  • #3 thread_dispatch
    at e-msgport.c line 1022
  • #4 _pthread_body

Thread 6 (process 8254 thread 0x2907)

  • #0 semaphore_wait_signal_trap
  • #1 pthread_cond_wait
  • #2 e_msgport_wait
    at e-msgport.c line 660
  • #3 thread_dispatch
    at e-msgport.c line 1022
  • #4 _pthread_body

Thread 5 (process 8254 thread 0x2a03)

  • #0 semaphore_wait_signal_trap
  • #1 pthread_cond_wait
  • #2 e_msgport_wait
    at e-msgport.c line 660
  • #3 thread_dispatch
    at e-msgport.c line 1022
  • #4 _pthread_body

Thread 3 (process 8254 thread 0x2603)

  • #0 semaphore_wait_signal_trap
  • #1 pthread_cond_wait
  • #2 e_msgport_wait
    at e-msgport.c line 660
  • #3 thread_dispatch
    at e-msgport.c line 1022
  • #4 _pthread_body

Thread 2 (process 8254 thread 0x1403)

  • #0 semaphore_wait_signal_trap
  • #1 pthread_cond_wait
  • #2 e_msgport_wait
    at e-msgport.c line 660
  • #3 thread_dispatch
    at e-msgport.c line 1022
  • #4 _pthread_body

Thread 1 (process 8254 local thread 0x1307)

  • #0 g_type_check_instance_cast
  • #1 field_changed_cb
    at task-details-page.c line 699
  • #2 g_closure_invoke
  • #3 signal_emit_unlocked_R
  • #4 g_signal_emit_valist
  • #5 g_signal_emit
  • #6 gtk_real_menu_shell_cancel
  • #7 g_closure_invoke
  • #8 signal_emit_unlocked_R
  • #9 g_signal_emit_valist
  • #10 g_signal_emit
  • #11 g_closure_invoke
  • #12 signal_emit_unlocked_R
  • #13 g_signal_emit_valist
  • #14 g_signal_emit
  • #15 gtk_grab_notify_foreach
  • #16 gtk_grab_notify
  • #17 gtk_window_show
  • #18 g_closure_invoke
  • #19 signal_emit_unlocked_R
  • #20 g_signal_emit_valist
  • #21 g_signal_emit
  • #22 gtk_widget_show
  • #23 task_editor_construct
    at task-editor.c line 434
  • #24 task_editor_new
    at task-editor.c line 645
  • #25 create_new_todo
    at tasks-component.c line 928
  • #26 create_local_item_cb
    at tasks-component.c line 961
  • #27 execute_verb
    at e-user-creatable-items-handler.c line 377
  • #28 default_activate
    at e-user-creatable-items-handler.c line 627
  • #29 g_closure_invoke
  • #30 signal_emit_unlocked_R
  • #31 g_signal_emit_valist
  • #32 gtk_signal_emit
  • #33 impl_released
    at e-combo-button.c line 381
  • #34 g_closure_invoke
  • #35 signal_emit_unlocked_R
  • #36 g_signal_emit_valist
  • #37 g_signal_emit
  • #38 gtk_button_button_release
  • #39 _gtk_marshal_BOOLEAN__BOXED
  • #40 g_closure_invoke
  • #41 signal_emit_unlocked_R
  • #42 g_signal_emit_valist
  • #43 g_signal_emit
  • #44 gtk_widget_event_internal
  • #45 gtk_propagate_event
  • #46 gtk_main_do_event
  • #47 gdk_event_dispatch
  • #48 g_main_dispatch
  • #49 g_main_context_iterate
  • #50 g_main_loop_run
  • #51 bonobo_main
  • #52 main
    at main.c line 606

Comment 1 Chenthill P 2006-01-11 05:14:18 UTC
Am not able to reproduce in Linux platforms. Is it reproducible ?
Comment 2 Christian Kirbach 2006-01-12 23:23:13 UTC
looks like a unique stack trace
Comment 3 André Klapper 2006-06-20 22:31:23 UTC
removing old target milestone.
Comment 4 Milan Crha 2007-11-01 17:27:25 UTC
I think this has been fixed recently (~ -3 months), there has been fixed reference counting problem, which is included in actual stable Evolution.
Can you try to reproduce with 2.12.x and later, please?
Comment 5 Tobias Mueller 2008-03-23 15:44:04 UTC
Closing as INCOMPLETE, might be OBSOLETE anyway.