Bug 969859

Let's make this a duplicate of bug #881948. The more I think of this the more I'm convinced it's the same thing, some use-after-free.

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

I hit this issue again with:
evolution-2.32.3-25.el6.x86_64
evolution-data-server-2.32.3-15.el6.x86_64
libsoup-2.28.2-4.el6.x86_64
glib2-2.26.1-3.el6.x86_64

I hit it when I tried to import a .vcf file to WebDAV addressbook that seems to have incorrect credentials (seeing 401's on the server and in e-a-f log).


Backtrace:

Thread 1 (Thread 0x7fb70cdfa700 (LWP 3119)):
#0  0x000000399f02a24b in g_cancellable_is_cancelled (cancellable=Traceback (most recent call last):
  File "/usr/share/glib-2.0/gdb/gobject.py", line 72, in to_string
    name = g_type_name_from_instance (self.val)
  File "/usr/share/glib-2.0/gdb/gobject.py", line 59, in g_type_name_from_instance
    name = g_type_to_name (gtype)
  File "/usr/share/glib-2.0/gdb/gobject.py", line 24, in g_type_to_name
    typenode = lookup_fundamental_type (typenode)
  File "/usr/share/glib-2.0/gdb/gobject.py", line 17, in lookup_fundamental_type
    return val[typenode >> 2].address()
TypeError: 'gdb.Value' object is not callable
) at gcancellable.c:410
No locals.
#1  0x00000039b48398d6 in soup_socket_connect_sync (sock=0x7fb73400d3a0, cancellable=Traceback (most recent call last):
  File "/usr/share/glib-2.0/gdb/gobject.py", line 72, in to_string
    name = g_type_name_from_instance (self.val)
  File "/usr/share/glib-2.0/gdb/gobject.py", line 59, in g_type_name_from_instance
    name = g_type_to_name (gtype)
  File "/usr/share/glib-2.0/gdb/gobject.py", line 24, in g_type_to_name
    typenode = lookup_fundamental_type (typenode)
  File "/usr/share/glib-2.0/gdb/gobject.py", line 17, in lookup_fundamental_type
    return val[typenode >> 2].address()
TypeError: 'gdb.Value' object is not callable
) at soup-socket.c:851
        priv = 0x7fb73400d3c0
        status = 4
        cancel_id = 19878
        __PRETTY_FUNCTION__ = "soup_socket_connect_sync"
#2  0x00000039b481f35e in soup_connection_connect_sync (conn=0x7fb708007920) at soup-connection.c:474
        priv = 0x7fb708007940
        status = <value optimized out>
        __PRETTY_FUNCTION__ = "soup_connection_connect_sync"
#3  0x00000039b4837bf8 in wait_for_connection (item=0x7fb708006400) at soup-session-sync.c:212
        msg = 0x7fb708008aa0 [SoupMessage]
        try_pruning = 0
        conn = 0x7fb708007920
        status = <value optimized out>
        session = 0x7fb738005680 [SoupSessionSync]
        priv = 0x7fb738005710
        proxy_resolver = <value optimized out>
        tunnel_addr = <value optimized out>
#4  process_queue_item (item=0x7fb708006400) at soup-session-sync.c:258
        priv = 0x7fb738005710
        conn = 0x7fb708007920
#5  0x00000039b4837d63 in send_message (session=<value optimized out>, msg=0x7fb708008aa0 [SoupMessage]) at soup-session-sync.c:322
        item = 0x7fb708006400
        status = <value optimized out>
        __PRETTY_FUNCTION__ = "send_message"
#6  0x00007fb740611a91 in send_and_handle_redirection (soup_session=0x7fb738005680 [SoupSessionSync], msg=0x7fb708008aa0 [SoupMessage], new_location=0x0) at e-cal-backend-caldav.c:933
        old_uri = 0x0
        __PRETTY_FUNCTION__ = "send_and_handle_redirection"
#7  0x00007fb7406160ac in caldav_server_list_objects (cbdav=<value optimized out>, objs=0x7fb70cdf9b90, len=0x7fb70cdf9b9c, only_hrefs=<value optimized out>, start_time=0, end_time=0) at e-cal-backend-caldav.c:1221
        priv = 0x16640e0
        buf = 0x7fb70802e910
        message = 0x7fb708008aa0 [SoupMessage]
        node = <value optimized out>
        sn = <value optimized out>
        root = 0x7fb70800ed20
        doc = 0x7fb70801ea30
        nsdav = <value optimized out>
        nscd = <value optimized out>
        result = 134278432
#8  0x00007fb740617804 in synchronize_cache (cbdav=0x1664060 [ECalBackendCalDAV], start_time=0, end_time=0) at e-cal-backend-caldav.c:1765
        priv = 0x16640e0
        bkend = 0x1664060 [ECalBackendCalDAV]
        sobjs = 0x0
        object = <value optimized out>
        c_objs = <value optimized out>
        c_iter = <value optimized out>
        c_uid2complist = <value optimized out>
        c_href2uid = <value optimized out>
        hrefs_to_update = <value optimized out>
        htu = <value optimized out>
        i = <value optimized out>
        len = 0
        __PRETTY_FUNCTION__ = "synchronize_cache"
#9  0x00007fb7406188ec in caldav_synch_slave_loop (data=<value optimized out>) at e-cal-backend-caldav.c:2078
        alarm_clock = {tv_sec = 1379368805, tv_usec = 601872}
        priv = 0x16640e0
        cbdav = 0x1664060 [ECalBackendCalDAV]
        now = 1379368805
        utc = 0x39b685cfc0
#10 0x000000399bc691b4 in g_thread_create_proxy (data=0x7fb738bb6c50) at gthread.c:1897
        thread = 0x7fb738bb6c50
        __PRETTY_FUNCTION__ = "g_thread_create_proxy"
#11 0x000000399ac079d1 in start_thread (arg=0x7fb70cdfa700) at pthread_create.c:301
        __res = <value optimized out>
        pd = 0x7fb70cdfa700
        now = <value optimized out>
        unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140424171726592, 1410749453927401812, 140425022585152, 140424171727296, 0, 3, -1369687368597288620, 1432365303628253524}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
        not_first_call = <value optimized out>
        pagesize_m1 = <value optimized out>
        sp = <value optimized out>
        freesize = <value optimized out>
#12 0x000000399a8e8a8d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
No locals.

Hmm, the new backtrace shows ECalBackendCalDAV, while you mention book factory. It's confusing. The import into a book might be unrelated to calendar factory. The only part in calendar factory which talks to book factory is a Birthdays & Anniversaries calendar, which checks people in configured books for those with filled birthday or an anniversary date.

What are your configured CalDAV calendars, please? The Google calendar is also CalDAV, but that is probably reachable also without VPN.

I tried to reproduce this, in various ways, with/without VPN, with/without network, suspend/resume done during the calendar refresh, but no crash so far.
I use libsoup-2.28.2-4.el6.x86_64.

Dan, could you have a look, please? As this is crashing in the libsoup code, maybe it'll ring a bell for you. I didn't find anything closely related in GNOME's bugzilla.

> What are your configured CalDAV calendars, please?

Sorry, I overlooked the question. I have one globally-accessible calendar and two accessible only through VPN or corporate network.

I only recently figured out the reason for bug #1049960 (RHEL7), while the same issue exists in RHEL6 too (or better can happen in some corner cases). It's probably not fully related to this issue, because it crashes in libsoup.

I'm moving this to libsoup, after a chat with Dan.

This is the synchronous version of the crash that was fixed in bug 657622, and the fix is just a two line addition to that patch; we need to hold an extra ref on the SoupSocket during soup_socket_connect_sync().

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0765.html