Bug 326327 – Evolution Crashed on Task creation

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


Summary:	Evolution Crashed on Task creation


Status:	RESOLVED OBSOLETE

Product:	evolution
Classification:	Applications
Component:	Tasks
Version:	2.6.x (obsolete)
Hardware:	Other Mac OS

Importance:	Normal normal
Target Milestone:	---
Assigned To:	Shreyas Srinivasan
QA Contact:	Evolution QA team

URL:
Whiteboard:

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 ()

+ Trace 65069

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.