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 688795 - [abrt] Crash under e_cal_backend_contacts_start_view()
[abrt] Crash under e_cal_backend_contacts_start_view()
Status: RESOLVED DUPLICATE of bug 701138
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.8.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2012-11-21 10:25 UTC by Milan Crha
Modified: 2015-01-05 17:53 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
eds patch (6.57 KB, patch)
2012-11-22 16:13 UTC, Milan Crha 		committed Details | Review

Description Milan Crha 2012-11-21 10:25:31 UTC 
Moving this from a downstream bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=878631

Version-Release number of selected component:
evolution-data-server-3.6.2-1.fc18

Additional info:
libreport version: 2.0.18
abrt_version:   2.0.18
backtrace_rating: 4
cmdline:        /usr/libexec/evolution-calendar-factory
crash_function: id_hash
kernel:         3.6.6-3.fc18.x86_64

Core was generated by `/usr/libexec/evolution-calendar-factory'.
Program terminated with signal 11, Segmentation fault.

+ Trace 231210

Thread 12 (Thread 0x7f3670250800 (LWP 1738))

  • #0 poll
    at ../sysdeps/unix/syscall-template.S line 81
  • #1 g_main_context_poll
    at gmain.c line 3584
  • #2 g_main_context_iterate
    at gmain.c line 3285
  • #3 g_main_loop_run
    at gmain.c line 3484
  • #4 dbus_server_run_server
    at e-dbus-server.c line 222
  • #5 ffi_call_unix64
    at ../src/x86/unix64.S line 75
  • #6 ffi_call
    at ../src/x86/ffi64.c line 486
  • #7 g_cclosure_marshal_generic_va
    at gclosure.c line 1550
  • #8 _g_closure_invoke_va
    at gclosure.c line 840
  • #9 g_signal_emit_valist
    at gsignal.c line 3211
  • #10 g_signal_emit
    at gsignal.c line 3356
  • #11 e_dbus_server_run
    at e-dbus-server.c line 396
  • #12 main
    at evolution-calendar-factory.c line 137 






Comment 1


Milan Crha





          2012-11-22 16:13:30 UTC
        



Created attachment 229641 [details] [review]
eds patch

for evolution-data-server;

I'm not 100% what caused this crash, the backtrace only shows that some garbage was passed to one function, but I guess it's due to multiple threads accessing tracked_contacts variable simultaneously, thus the calendar component was removed while other thread used it. This patch adds locking around tracked_contacts variable, thus this should not happen again.






Comment 2


Milan Crha





          2012-11-22 16:15:50 UTC
        



Created commit 3862144 in eds master (3.7.3+)
Created commit 8b90c45 in eds gnome-3-6 (3.6.3+)






Comment 3


Milan Crha





          2013-09-30 08:27:05 UTC
        



Reopening, 3.8.5 still suffers of the crash:
https://bugzilla.redhat.com/show_bug.cgi?id=1013186






Comment 4


Milan Crha





          2014-04-29 14:13:55 UTC
        



Also 3.10.3:
https://bugzilla.redhat.com/show_bug.cgi?id=1091746

Core was generated by `/usr/libexec/evolution-calendar-factory'.
Program terminated with signal SIGSEGV, Segmentation fault.




+
Trace
    233535






Thread 1
          (Thread 0x7fe128ff9700 (LWP 32286))


    

  • 
#0
id_hash

    
                at e-data-cal-view.c
                  line
                  138

    

    • 

  • 
#1
g_hash_table_lookup_node

    
                at ghash.c
                  line
                  365

    

    • 

  • 
#2
g_hash_table_insert_internal

    
                at ghash.c
                  line
                  1153

    

    • 

  • 
#3
notify_add_component

    
                at e-data-cal-view.c
                  line
                  728

    

    • 

  • 
#4
e_data_cal_view_notify_components_added

    
                at e-data-cal-view.c
                  line
                  1180

    

    • 

  • 
#5
e_cal_backend_http_start_view

    
                at e-cal-backend-http.c
                  line
                  1171

    

    • 

  • 
#6
calview_start_thread

    
                at e-data-cal-view.c
                  line
                  174

    

    • 

  • 
#7
g_thread_proxy

    
                at gthread.c
                  line
                  798

    

    • 

  • 
#8
start_thread

    
                at pthread_create.c
                  line
                  309

    

    • 

  • 
#9
clone

    
                at ../sysdeps/unix/sysv/linux/x86_64/clone.S
                  line
                  111

    

    • 













Comment 5


Christian Stadelmann





          2014-06-20 11:21:54 UTC
        



I keep running into this bug (downstream: https://bugzilla.redhat.com/show_bug.cgi?id=1091746 ). Do you need more info?
This bug may be related to snoozing a alarm notify to another date (in my time zone).






Comment 6


Milan Crha





          2014-06-23 08:39:43 UTC
        



(In reply to comment #5)
> I keep running into this bug (downstream:
> https://bugzilla.redhat.com/show_bug.cgi?id=1091746 ). Do you need more info?
> This bug may be related to snoozing a alarm notify to another date (in my time
> zone).

I suppose it's still this e_cal_backend_http_start_view(). As it involves On The Web calendar, is the calendar publicly accessible? If it is, I may try to configure it here and hopefully reproduce the issue.






Comment 7


James





          2014-08-08 03:32:10 UTC
        



abrt ultimately sends me here...

I routinely and constantly get notification messages in evolution that say:

The calendar backend servicing "<CALENDAR NAME>" has quit unexpectedly.

Since I have more than one calendar (I have N), N of these dialogs pop up, each with the respective name where I put <CALENDAR NAME>.

This is particularly annoying.

Fixes appreciated :)






Comment 8


Milan Crha





          2014-08-27 06:49:06 UTC
        



(In reply to comment #7)
> Fixes appreciated :)

Please see comment #6, I am not able to reproduce this. Having a calendar which causes the crash I would be able to investigate this further and eventually fix it. By the way, what are your calendars you've configured (CalDAV, On The Web, Birthdays & Anniversaries, ...)?






Comment 9


James





          2014-08-27 08:03:15 UTC
        



(In reply to comment #8)
> (In reply to comment #7)
> > Fixes appreciated :)
> 
> Please see comment #6, I am not able to reproduce this. Having a calendar which
> causes the crash I would be able to investigate this further and eventually fix
> it. By the way, what are your calendars you've configured (CalDAV, On The Web,
> Birthdays & Anniversaries, ...)?

No calendars are public, but I can run in gdb and then run commands as needed. The problem is that the whole program doesn't crash, so you'll have to recommend what to do in gdb to help you.

As for calendars:
1) "On This Computer": 3 different calendars
2) "CalDAV": 2 different calendars
3) "Contacts" 1 Birthdays and Anniversaries
4) "Google": 2 Different calendars
5) "On The Web" 2 Different calendars: 1 facebook, 1 facebook birthdays

So I guess I have a lot of calendars. Click the "quit unexpectedly" close button 10 times quite often is annoying!

Let me know if you need more info.

Cheers,
James






Comment 10


Milan Crha





          2014-08-29 08:04:19 UTC
        



Oh, I'm sorry, I missed one point. The crash happens in the Birthdays and Anniversaries calendar, thus you have it selected in Calendars UI. This calendar asks all the books, which are configured for it, for contacts with birthdays. The point I missed is that the configured calendars are not that important as the configured address books, which are set to be Used for Birthdays and Anniversaries calendar (in an address book properties). At least if ABRT identified this bug report as a duplicate of your crash properly.






Comment 11


Milan Crha





          2014-12-05 14:07:32 UTC
        



Maybe this is another instance of bug #701138.






Comment 12


Milan Crha





          2015-01-05 17:53:09 UTC
        



(In reply to comment #11)
> Maybe this is another instance of bug #701138.

I believe it is, thus I mark it as such.

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