GNOME Bugzilla – Bug 681665
Crash during fetch of the OAB url
Last modified: 2013-08-30 10:55:13 UTC
Starting program: /usr/bin/evolution warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffe757e700 (LWP 19979)] [New Thread 0x7fffe6d4c700 (LWP 19980)] [New Thread 0x7fffe654b700 (LWP 19981)] [New Thread 0x7fffe5d4a700 (LWP 19982)] [New Thread 0x7fffc616d700 (LWP 19983)] [New Thread 0x7fffc596c700 (LWP 19984)] [New Thread 0x7fffc516b700 (LWP 19985)] [New Thread 0x7fffc496a700 (LWP 19986)] [New Thread 0x7fffb7fff700 (LWP 19987)] [New Thread 0x7fffb77fe700 (LWP 19988)] [New Thread 0x7fffb61bb700 (LWP 19989)] [New Thread 0x7fffb59ba700 (LWP 19990)] [New Thread 0x7fffb4fb3700 (LWP 19991)] [New Thread 0x7fff6fffd700 (LWP 19992)] [New Thread 0x7fff6f7fc700 (LWP 19993)] [New Thread 0x7fff6effb700 (LWP 19994)] [Thread 0x7fff6f7fc700 (LWP 19993) exited] [Thread 0x7fffb61bb700 (LWP 19989) exited] [Thread 0x7fffb59ba700 (LWP 19990) exited] [New Thread 0x7fffb59ba700 (LWP 20000)] [New Thread 0x7fffb61bb700 (LWP 20001)] [Thread 0x7fff6fffd700 (LWP 19992) exited] [Thread 0x7fffc616d700 (LWP 19983) exited] [New Thread 0x7fffc616d700 (LWP 20002)] [Thread 0x7fffc516b700 (LWP 19985) exited] [Thread 0x7fff6effb700 (LWP 19994) exited] [Thread 0x7fffc496a700 (LWP 19986) exited] [New Thread 0x7fffc496a700 (LWP 20003)] [Thread 0x7fffc496a700 (LWP 20003) exited] [New Thread 0x7fffc496a700 (LWP 20005)] [New Thread 0x7fff6effb700 (LWP 20006)] [Thread 0x7fffc496a700 (LWP 20005) exited] [Thread 0x7fffc596c700 (LWP 19984) exited] [New Thread 0x7fffc596c700 (LWP 20009)] [Thread 0x7fffc596c700 (LWP 20009) exited] [New Thread 0x7fffc596c700 (LWP 20014)] [New Thread 0x7fffc496a700 (LWP 20015)] [Thread 0x7fffc496a700 (LWP 20015) exited] [New Thread 0x7fffc516b700 (LWP 20016)] [Thread 0x7fffc516b700 (LWP 20016) exited] [New Thread 0x7fffc496a700 (LWP 20017)] [Thread 0x7fffc496a700 (LWP 20017) exited] [New Thread 0x7fffc496a700 (LWP 20018)] [Thread 0x7fffc496a700 (LWP 20018) exited] [New Thread 0x7fffc496a700 (LWP 20019)] [New Thread 0x7fffc516b700 (LWP 20020)] [New Thread 0x7fff6fffd700 (LWP 20021)] [Thread 0x7fffc496a700 (LWP 20019) exited] [Thread 0x7fffc516b700 (LWP 20020) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffc596c700 (LWP 20014)] autodiscover_response_cb (session=<optimized out>, msg=0x2dd4bf0, data=0x7fff5400cc40) at e-ews-connection.c:1851 1851 e-ews-connection.c: No such file or directory.
+ Trace 230658
Thread 24 (Thread 0x7fff6affb700 (LWP 20117))
Thread 1 (Thread 0x7fffe9ae0940 (LWP 20083))
Inferior 1 [process 20083] will be killed. Quit anyway? (y or n)
Thanks for a bug report. Could you retest with the latest git master (or 3.5.90+), please? There was one issue fixed with the autodiscovery, and it works fine here, thus I'm wondering whether the fix helped on your side too. Thanks in advance.
(In reply to comment #1) > Thanks for a bug report. Could you retest with the latest git master (or > 3.5.90+), please? There was one issue fixed with the autodiscovery, and it > works fine here, thus I'm wondering whether the fix helped on your side too. > Thanks in advance. Sorry - I currently have problems (dependency hell) running GNOME 3.5 so I am using 3.4 only. I might try jhbuild over weekend.
I finally managed to run gnome-shell 3.6. Reproduced on 3.6. Starting program: /usr/bin/evolution warning: Could not load shared library symbols for linux-vdso.so.1. Do you need "set solib-search-path" or "set sysroot"? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffd92b4700 (LWP 15338)] [New Thread 0x7fffd39c1700 (LWP 15339)] [New Thread 0x7fffd31c0700 (LWP 15340)] [New Thread 0x7fffd29bf700 (LWP 15341)] [New Thread 0x7fffb676f700 (LWP 15344)] [New Thread 0x7fffb5f6e700 (LWP 15348)] [New Thread 0x7fffb576d700 (LWP 15349)] [New Thread 0x7fffb4f6c700 (LWP 15350)] [New Thread 0x7fffa7fff700 (LWP 15351)] [New Thread 0x7fffa77fe700 (LWP 15352)] [New Thread 0x7fffa6ffd700 (LWP 15353)] [New Thread 0x7fffa67fc700 (LWP 15354)] [New Thread 0x7fffa53c5700 (LWP 15355)] [New Thread 0x7fffa4bc4700 (LWP 15356)] [Thread 0x7fffa4bc4700 (LWP 15356) exited] [Thread 0x7fffb5f6e700 (LWP 15348) exited] [Thread 0x7fffa53c5700 (LWP 15355) exited] [New Thread 0x7fffa53c5700 (LWP 15362)] [Thread 0x7fffa77fe700 (LWP 15352) exited] [Thread 0x7fffa7fff700 (LWP 15351) exited] [New Thread 0x7fffa7fff700 (LWP 15366)] [Thread 0x7fffb576d700 (LWP 15349) exited] [Thread 0x7fffb4f6c700 (LWP 15350) exited] [Thread 0x7fffb676f700 (LWP 15344) exited] [Thread 0x7fffa53c5700 (LWP 15362) exited] [Thread 0x7fffa7fff700 (LWP 15366) exited] [New Thread 0x7fffa7fff700 (LWP 15417)] [Thread 0x7fffa7fff700 (LWP 15417) exited] [New Thread 0x7fffa7fff700 (LWP 15421)] [New Thread 0x7fffa53c5700 (LWP 15422)] [New Thread 0x7fffb676f700 (LWP 15423)] [New Thread 0x7fffb4f6c700 (LWP 15424)] [Thread 0x7fffa53c5700 (LWP 15422) exited] [Thread 0x7fffb4f6c700 (LWP 15424) exited] [Thread 0x7fffa7fff700 (LWP 15421) exited] [New Thread 0x7fffb4f6c700 (LWP 15425)] [New Thread 0x7fffa7fff700 (LWP 15426)] [Thread 0x7fffa7fff700 (LWP 15426) exited] [Thread 0x7fffb676f700 (LWP 15423) exited] [New Thread 0x7fffa7fff700 (LWP 15436)] [Thread 0x7fffa7fff700 (LWP 15436) exited] [Thread 0x7fffb4f6c700 (LWP 15425) exited] [New Thread 0x7fffb4f6c700 (LWP 15443)] [New Thread 0x7fffa7fff700 (LWP 15447)] [New Thread 0x7fffb676f700 (LWP 15448)] [Thread 0x7fffb676f700 (LWP 15448) exited] [New Thread 0x7fffa53c5700 (LWP 15450)] [New Thread 0x7fffb676f700 (LWP 15451)] [New Thread 0x7fffa77fe700 (LWP 15452)] [Thread 0x7fffb676f700 (LWP 15451) exited] [Thread 0x7fffa53c5700 (LWP 15450) exited] [Thread 0x7fffa77fe700 (LWP 15452) exited] [New Thread 0x7fffa53c5700 (LWP 15453)] [New Thread 0x7fffa77fe700 (LWP 15454)] [New Thread 0x7fffb676f700 (LWP 15455)] [New Thread 0x7fffa4bc4700 (LWP 15456)] [New Thread 0x7fff53dec700 (LWP 15458)] [New Thread 0x7fff535eb700 (LWP 15459)] [New Thread 0x7fff52dea700 (LWP 15460)] [Thread 0x7fffa53c5700 (LWP 15453) exited] [Thread 0x7fffa4bc4700 (LWP 15456) exited] [New Thread 0x7fffa4bc4700 (LWP 15467)] [Thread 0x7fffa4bc4700 (LWP 15467) exited] [New Thread 0x7fffa4bc4700 (LWP 15468)] [Thread 0x7fffa4bc4700 (LWP 15468) exited] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffa7fff700 (LWP 15447)] autodiscover_response_cb (session=<optimized out>, msg=0x7fff9c021140, data=0x25840b0) at e-ews-connection.c:1827 1827 e-ews-connection.c: No such file or directory.
+ Trace 230922
Thread 27 (Thread 0x7fffa7fff700 (LWP 15447))
Thread 1 (Thread 0x7ffff7f92940 (LWP 15335))
Inferior 1 [process 15335] will be killed. Quit anyway? (y or n)
Created attachment 225371 [details] [review] 0001-Treat-lack-of-the-autodiscovery-data-as-cancellation.patch After this patch is applied evolution don't crash any more. However - relevant output with added printf of parameters + ad + idx: autodiscover_response_cb(0x2127bd0, 0x7fffa80160a0, 0x257ee00): 0x7fffd4044230, 1 autodiscover_response_cb(0x2127bd0, 0x20f6680, 0x257ee00): 0x7fffd4044230, 0 (evolution:9897): GLib-GIO-CRITICAL **: g_simple_async_result_get_op_res_gpointer: assertion `G_IS_SIMPLE_ASYNC_RESULT (simple)' failed autodiscover_response_cb(0x2127bd0, 0x7fffa8016180, 0x257ee00): (nil), 0 (evolution:9897): GLib-GIO-CRITICAL **: g_simple_async_result_get_op_res_gpointer: assertion `G_IS_SIMPLE_ASYNC_RESULT (simple)' failed autodiscover_response_cb(0x2127bd0, 0x7fffa8016260, 0x257ee00): (nil), 0 It looks like the async result were terminated before calling into function.
Thanks for the update. Just for a record, in 3.6.0: 1824 ad = g_simple_async_result_get_op_res_gpointer (simple); 1825 1826 for (idx = 0; idx < 4; idx++) { 1827 if (ad->msgs[idx] == msg) // << crashes here 1828 break; 1829 } I suppose you see the same runtime warnings even without the patch, which might make sense, because 'ad' is NULL for you, due to failed g_simple_async_result_get_op_res_gpointer() call. Are you able to reproduce this under valgrind? It may show where the 'simple' was freed, but as I expect this being about "proper" timing, then I'm not much sure whether you'll be able to reproduce this with slower run under valgrind. I usually use command like this: $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt By the way, is this when you run evolution for the first time, when there is no account configured, or when you add new ews account from Edit->Preferences->Mail Account->Add (or similarly File->New->Mail Account)?
Created attachment 226881 [details] Valgrind log for evolution I've noticed that if I add email USER@SERVER and the login is LOGIN when USER !=LOGIN then it crashes. If USER == LOGIN then it succeeds for the same server. (In reply to comment #5) > Thanks for the update. Just for a record, in 3.6.0: > > 1824 ad = g_simple_async_result_get_op_res_gpointer (simple); > 1825 > 1826 for (idx = 0; idx < 4; idx++) { > 1827 if (ad->msgs[idx] == msg) // << crashes here > 1828 break; > 1829 } > > I suppose you see the same runtime warnings even without the patch, which might > make sense, because 'ad' is NULL for you, due to failed > g_simple_async_result_get_op_res_gpointer() call. Are you able to reproduce > this under valgrind? It may show where the 'simple' was freed, but as I expect > this being about "proper" timing, then I'm not much sure whether you'll be able > to reproduce this with slower run under valgrind. > > I usually use command like this: > $ G_SLICE=always-malloc valgrind --num-callers=50 evolution &>log.txt > Attached. However I would look into other errors shown as well (There read after free, reading after end of allocation etc.) Some of them like g_utf8_collate_key might be false negatives and be just vector instructions optimizations though. > By the way, is this when you run evolution for the first time, when there is no > account configured, or when you add new ews account from > Edit->Preferences->Mail Account->Add (or similarly File->New->Mail Account)? By Edit->Preferences->Mail Account->Add. I wanted to switch to goa account but I run into bug #685090 so I tried to add it back to Evolution.
Thanks for the update. You are right with the false positives, at least all the group about wcslen should be suppressed (I have it on my machine). The group of issues involving cairo is new to me. The one for WebKit::DOMObjectCache::clearByFrame is fixed in upstream of WebKit, but also only recently. I've no information about WebCore::PluginDatabase::add. The end of the log contains the crash information, showing there happened crash for use-after-free: Thread 9: Invalid read of size 8 at 0x83CF9AE: g_simple_async_result_get_op_res_gpointer by 0x2ACC5D98: autodiscover_response_cb by 0xAC09C0D: process_queue_item (in /usr/lib64/libsoup-2.4.so.1.5.0) by 0xAC0A211: soup_session_async_cancel_message by 0xAC0733B: soup_session_cancel_message by 0x2ACC4CF7: ews_connection_scheduled_cb by 0x894A182: g_main_context_dispatch by 0x894A4CF: g_main_context_iterate.isra.25 by 0x894A8B9: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3400.1) by 0x2ACC2C8D: e_ews_soup_thread by 0x896BFC4: g_thread_proxy (in /usr/lib64/libglib-2.0.so.0.3400.1) by 0x8C2AEA5: start_thread (in /lib64/libpthread-2.15.so) by 0x8F2970C: clone (in /lib64/libc-2.15.so) Address 0x3fe11000 is 0 bytes inside a block of size 104 free'd at 0x4C299B9: free (vg_replace_malloc.c:446) by 0x86E4463: g_type_free_instance by 0x59B7F30: e_async_closure_free by 0x2ACCB7DC: e_ews_autodiscover_ws_url_sync by 0x2FA02C57: mail_config_ews_autodiscover_try_password_sync by 0x59AC2FD: source_registry_authenticate_authenticate_cb by 0x133E6EAB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.0) by 0x133E6904: ffi_call (in /usr/lib64/libffi.so.6.0.0) by 0x86C47B7: g_cclosure_marshal_generic by 0x86C3FAE: g_closure_invoke by 0x86D4D70: signal_emit_unlocked_R by 0x86DBF48: g_signal_emitv by 0x59C3A2F: e_dbus_authenticator_proxy_g_signal by 0x133E6EAB: ffi_call_unix64 (in /usr/lib64/libffi.so.6.0.0) by 0x133E6904: ffi_call (in /usr/lib64/libffi.so.6.0.0) by 0x86C47B7: g_cclosure_marshal_generic by 0x86C3FAE: g_closure_invoke by 0x86D5338: signal_emit_unlocked_R by 0x86DCD31: g_signal_emit_valist by 0x86DCED9: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.3400.1) by 0x8429AD3: on_signal_received (in /usr/lib64/libgio-2.0.so.0.3400.1) by 0x8419E84: emit_signal_instance_in_idle_cb by 0x894A182: g_main_context_dispatch by 0x894A4CF: g_main_context_iterate.isra.25 by 0x894A8B9: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3400.1) by 0x59AE9F8: e_source_registry_authenticate_sync by 0x59AEA80: source_registry_authenticate_thread by 0x83D028B: run_in_thread by 0x83BE885: io_job_thread by 0x896C7E7: g_thread_pool_thread_proxy by 0x896BFC4: g_thread_proxy (in /usr/lib64/libglib-2.0.so.0.3400.1) by 0x8C2AEA5: start_thread (in /lib64/libpthread-2.15.so) by 0x8F2970C: clone (in /lib64/libc-2.15.so)
Created attachment 226998 [details] [review] proposed ews patch for evolution-ews; Could you try with this patch, please? I'm still unable to reproduce this error, but I guess this reference change on 'simple' will help to avoid your crash. I think it's either because of your server or client machine being quicker than mine. Please run evolution from console while testing, and make sure there will be no runtime critical warnings (about assertions). Thanks in advance.
Patch works for me.
Thanks for the testing and confirmation, I'm committing this into sources: Created commit 1e4326a in ews master (3.7.2+) Created commit 91959c5 in ews gnome-3-6 (3.6.2+)
*** Bug 689129 has been marked as a duplicate of this bug. ***