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 318665 - calender factory does not find backend in hash, overwrites it -> assertion failure "priv->clients == NULL"
calender factory does not find backend in hash, overwrites it -> assertion fa...
Status: RESOLVED DUPLICATE of bug 317897
Product: Evolution Exchange
Classification: Deprecated
Component: Connector
1.0.x
Other Linux
: Normal blocker
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-10-12 13:21 UTC by Patrick Ohly
Modified: 2005-11-10 19:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Patrick Ohly 2005-10-12 13:21:02 UTC
Version details: 1.4.1
Distribution/Version: Red Hat 9.0

Preparation:
a. use Exchange connector to access Exchange calender
b. look at a meeting invitation email, enter it to calender if necessary

Restart Evolution (might not be necessary),
have the message preview open:

1. look at the meeting invitation email: it is said to be found in calender
2. switch to a normal email (I switched to a different folder for that)
3. switch back to the invitation email

Evolution exchange connector dies, error is:
libedata-cal-ERROR **: file e-cal-backend.c: line 294 (e_cal_backend_finalize):
assertion failed: (priv->clients == NULL)
aborting...

I investigated this in a debugger. What I found is that
in 1., the function impl_CalFactory_getCal() from e-data-cal-factory.c
creates the backend for the first time and adds it to the hash with
the key "exchange://pohly%40GER;auth=Basic@email.intel.com/;personal/Calendar:4".

Then in 3. lookup_backend() searches the hash with a truncated
url string "exchange://pohly@GER;auth=Basic@email.intel.com/" which yields
no result, so impl_CalFactory_getCal() creates another instance.
While adding it, the hash code automatically deletes the old instance and
that complains with the assert above (presumably because it is still in use).

I used garnome-2.12.1 to compile from source. Here is a patch which fixes
the problem. It does no error checking and probably creating the key should
be moved into a separate function to avoid code duplication.

*** evolution-data-server-1.4.1/calendar/libedata-cal/e-data-cal-factory.c.orig
2005-10-12 14:36:05.000000000 +0200
--- evolution-data-server-1.4.1/calendar/libedata-cal/e-data-cal-factory.c     
2005-10-12 14:39:30.000000000 +0200
***************
*** 238,245 ****
                        goto cleanup;
                }
  
!               /* Track the backend */
!               g_hash_table_insert (priv->backends, g_strdup (uri_type_string),
backend);
  
                g_signal_connect (G_OBJECT (backend), "last_client_gone",
                                  G_CALLBACK (backend_last_client_gone_cb),
--- 238,256 ----
                        goto cleanup;
                }
  
!               /* Track the backend, using the same key as in lookup_backend() */
!                 {
!                     EUri *uri;
!                     char *key;
!                     uri = e_uri_new (uri_type_string);
!                     if (!uri) {
!                         /* error handling? */
!                     }
!                     key = e_uri_to_string (uri, FALSE);
!                     e_uri_free (uri);
! 
!                     g_hash_table_insert (priv->backends, key, backend);
!                 }
  
                g_signal_connect (G_OBJECT (backend), "last_client_gone",
                                  G_CALLBACK (backend_last_client_gone_cb),
Comment 1 Chenthill P 2005-10-17 06:05:10 UTC
This is an exchange specific problem, moving it to exchange connector.
Comment 2 Patrick Ohly 2005-10-17 06:37:56 UTC
Why is this an Exchange connector problem when the faulty code is in
evolution-data-server-1.4.1/calendar/libedata-cal/e-data-cal-factory.c?
My impression is that this would also affect any other calender
backend with unusual URLs.
Comment 3 Patrick Ohly 2005-11-10 19:40:37 UTC

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