Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 969859 - [abrt] Crash under soup_socket_connect_sync()
[abrt] Crash under soup_socket_connect_sync()
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libsoup (Show other bugs)
x86_64 Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Dan Winship
Desktop QE
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2013-06-02 14:50 EDT by David Jaša
Modified: 2016-05-10 16:05 EDT (History)
6 users (show)

See Also:
Fixed In Version: libsoup-2.34.3-4.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-05-10 16:05:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:0765 normal SHIPPED_LIVE libsoup bug fix update 2016-05-10 18:34:00 EDT

  None (edit)
Description David Jaša 2013-06-02 14:50:35 EDT
Description of problem:
e-calendar-factory crashed shortly after resume from S3 sleep and online/offline cycle, when some caldav calendars weren't reachable.

Version-Release number of selected component:

Additional info:
libreport version: 2.0.9
abrt_version:   2.0.8
backtrace_rating: 4
cmdline:        /usr/libexec/e-calendar-factory
crash_function: g_cancellable_is_cancelled
kernel:         2.6.32-358.6.1.el6.x86_64

truncated backtrace:
:Thread no. 1 (10 frames)
: #0 g_cancellable_is_cancelled at gcancellable.c
: #1 soup_socket_connect_sync at soup-socket.c
: #2 soup_connection_connect_sync at soup-connection.c
: #3 wait_for_connection at soup-session-sync.c
: #4 process_queue_item at soup-session-sync.c
: #5 send_message at soup-session-sync.c
: #6 send_and_handle_redirection at e-cal-backend-caldav.c
: #7 caldav_server_list_objects at e-cal-backend-caldav.c
: #8 synchronize_cache at e-cal-backend-caldav.c
: #9 caldav_synch_slave_loop at e-cal-backend-caldav.c
Comment 2 Milan Crha 2013-06-13 13:05:49 EDT
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 ***
Comment 3 David Jaša 2013-09-17 07:19:45 EDT
I hit this issue again with:

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


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.
Comment 4 Milan Crha 2013-09-17 09:10:20 EDT
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.
Comment 5 Milan Crha 2013-09-18 07:25:30 EDT
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.
Comment 6 David Jaša 2013-09-21 17:38:50 EDT
> 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.
Comment 7 Milan Crha 2014-01-23 10:22:58 EST
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.
Comment 8 Milan Crha 2014-01-23 10:51:35 EST
I'm moving this to libsoup, after a chat with Dan.
Comment 9 Dan Winship 2014-01-23 11:02:31 EST
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().
Comment 15 errata-xmlrpc 2016-05-10 16:05:53 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.