Hide Forgot
Description of problem: abrt version: 1.1.16 architecture: x86_64 Attached file: backtrace, 18587 bytes cmdline: /usr/libexec/evolution-data-server-2.28 --oaf-activate-iid=OAFIID:GNOME_Evolution_DataServer_InterfaceCheck --oaf-ior-fd=30 component: evolution-data-server Attached file: coredump, 89509888 bytes crash_function: strlen executable: /usr/libexec/evolution-data-server-2.28 kernel: 2.6.32-131.0.15.el6.x86_64 rating: 1 reason: Process /usr/libexec/evolution-data-server-2.28 was killed by signal 11 (SIGSEGV) Attached file: sosreport.tar.xz, 610936 bytes time: 1306943783 uid: 500 Version-Release number of selected component (if applicable): release: Red Hat Enterprise Linux Client release 6.1 (Santiago) evolution-data-server-2.28.3-15.el6 How reproducible: random crash Steps to Reproduce: 1.Using Evolution 2.Adding a email address in CC field Actual results: evolution-data-server crashed Expected results: evolution-data-server should not crashed Additional info:
Created attachment 503158 [details] Backtrace, Dissassembly
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux. If you would like it considered as an exception in the current release, please ask your support representative.
I suppose it's because vcard being NULL in the lowest frame, which propagates up to the top. Checking the upstream code, this will be obsolete with the rebase to 2.32.3, because that version uses GDBus instead. With that there might be good to backport patch from [1] instead. [1] https://bugzilla.gnome.org/show_bug.cgi?id=654472 Thread 1 (Thread 0x7fb1021fc700 (LWP 9688)): #0 __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 No locals. #1 0x000000313e62a981 in giop_send_buffer_append_string (buf=0x1733c00, str=0x0) at giop-send-buffer.c:542 ---Type <return> to continue, or q <return> to quit--- len = <value optimized out> #2 0x000000313e638e3c in ORBit_marshal_value (buf=0x1733c00, val=0x7fb1021fb880, tc=0x313e86a060) at corba-any.c:229 i = <value optimized out> ulval = <value optimized out> subval = <value optimized out> #3 0x000000313e62f46c in orbit_small_marshal (obj=<value optimized out>, cnx=0x7fb104006d80 [GIOPConnection], mqe=<value optimized out>, request_id=<value optimized out>, m_data=0x3137c26700, args=<value optimized out>, ctx=<value optimized out>) at orbit-small.c:355 a = <value optimized out> p = 0x7fb1021fb9c0 send_buffer = 0x1733c00 op_vec = {iov_base = 0x7fb1021fb810, iov_len = 28} tc = <value optimized out> i = <value optimized out> #4 0x000000313e6309df in ORBit_small_invoke_stub (obj=0x7fb0f40972d0, m_data=0x3137c26700, ret=<value optimized out>, args= 0x7fb1021fb9d0, ctx=<value optimized out>, ev=0x7fb1021fba00) at orbit-small.c:648 completion_status = CORBA_COMPLETED_NO cnx = 0x7fb104006d80 [GIOPConnection] mqe = {buffer = 0x0, cnx = 0x7fb104006d80 [GIOPConnection], msg_type = 1, request_id = 35633432, src_thread = 0x7fb118004a50, async_cb = 0} adaptor_obj = <value optimized out> recv_buffer = 0x0 xt_proxy = 0x0 invoke_policy = 0x0 timeout = 0 #5 0x0000003137a0f755 in GNOME_Evolution_Addressbook_BookListener_notifyContactRequested (_obj=<value optimized out>, opid=0, status= GNOME_Evolution_Addressbook_RepositoryOffline, vcard=0x0, ev=<value optimized out>) at Evolution-DataServer-Addressbook-stubs.c:258 _args = {0x7fb1021fb9cc, 0x7fb1021fb9c8, 0x7fb1021fb9c0} #6 0x0000003137a1b919 in e_data_book_respond_get_contact (book=0x7fb104004180 [EDataBook], opid=0, status= GNOME_Evolution_Addressbook_RepositoryOffline, vcard=0x0) at e-data-book.c:687 ev = {_id = 0x0, _major = 0, _any = {_type = 0x0, _value = 0x0, _release = 0 '\000'}}
I tried to reproduce this under 2.32.3, with no succcess. The code also changed in rebase, thus I'm devel-nacking this.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.