Created attachment 1376286 [details]
File: cgroup

Created attachment 1376287 [details]
File: core_backtrace

Created attachment 1376288 [details]
File: cpuinfo

Created attachment 1376289 [details]
File: dso_list

Created attachment 1376290 [details]
File: environ

Created attachment 1376291 [details]
File: limits

Created attachment 1376292 [details]
File: maps

Created attachment 1376293 [details]
File: mountinfo

Created attachment 1376294 [details]
File: open_fds

Created attachment 1376295 [details]
File: proc_pid_status

Thanks for a bug report. If I read the backtrace properly, the one of your LDAP address books decided to populate/refresh its cache, but it wasn't connected, which led to the crash, due to assert of "ld != NULL" in LDAP's ldap_pvt_search() function.

I guess it begun the local cache update when it had been connected (there's a code to not start cache update when it's not connected), but during the update the backend disconnected, which led to the crash due to insufficient checking of the connected state.

Related part of the backtrace:

Thread 1 (Thread 0x7f5a54e0af80 (LWP 8456)):
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
        set = {__val = {0, 94408559720128, 0, 140025721776511, 140028746235904, 94408559720128, 94408559720229, 94408559720128, 94408559720128, 94408559720231, 94408559720428, 94408559720128, 94408559720428, 0, 0, 0}}
        pid = <optimized out>
        tid = <optimized out>
#1  0x00007f5a47637381 in __GI_abort () at abort.c:79
        save_stage = 1
        act = {__sigaction_handler = {sa_handler = 0x7f5a2a812070, sa_sigaction = 0x7f5a2a812070}, sa_mask = {__val = {0, 6, 0, 0, 0, 140734020229944, 0, 140734020229776, 140025723012368, 21474836480, 140025722997672, 0, 14591080432356557568, 140025722982710, 0, 140025722997672}}, sa_flags = 363401078, sa_restorer = 0x7f5a15a968a8}
        sigs = {__val = {32, 0 <repeats 15 times>}}
#2  0x00007f5a4762d8fa in __assert_fail_base (fmt=0x7f5a477a8ba8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7f5a15a968a8 "ld != NULL", file=file@entry=0x7f5a15a90f76 "search.c", line=line@entry=95, function=function@entry=0x7f5a15a91060 <__PRETTY_FUNCTION__.8240> "ldap_pvt_search") at assert.c:92
        str = 0x7f5a2a812070 ""
        total = 4096
#3  0x00007f5a4762d972 in __GI___assert_fail (assertion=assertion@entry=0x7f5a15a968a8 "ld != NULL", file=file@entry=0x7f5a15a90f76 "search.c", line=line@entry=95, function=function@entry=0x7f5a15a91060 <__PRETTY_FUNCTION__.8240> "ldap_pvt_search") at assert.c:101
No locals.
#4  0x00007f5a15a649c9 in ldap_pvt_search (ld=ld@entry=0x0, base=0x55dd38a8e390 "...", scope=scope@entry=0, filter=filter@entry=0x0, attrs=attrs@entry=0x7fff31489dd0, attrsonly=attrsonly@entry=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=100, deref=-1, msgidp=0x7fff31489ca4) at search.c:95
        rc = <optimized out>
        ber = <optimized out>
        timelimit = <optimized out>
        id = 0
        __PRETTY_FUNCTION__ = "ldap_pvt_search"
#5  0x00007f5a15a64a6e in ldap_pvt_search_s (ld=0x0, base=<optimized out>, scope=scope@entry=0, filter=filter@entry=0x0, attrs=attrs@entry=0x7fff31489dd0, attrsonly=attrsonly@entry=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=100, deref=-1, res=0x7fff31489dc8) at search.c:174
        rc = <optimized out>
        msgid = 0
#6  0x00007f5a15a64b20 in ldap_search_ext_s (ld=<optimized out>, base=<optimized out>, scope=scope@entry=0, filter=filter@entry=0x0, attrs=attrs@entry=0x7fff31489dd0, attrsonly=attrsonly@entry=0, sctrls=0x0, cctrls=0x0, timeout=0x0, sizelimit=100, res=0x7fff31489dc8) at search.c:150
No locals.
#7  0x00007f5a15ebd7ba in build_contact_from_entry (bl=bl@entry=0x55dd326783d0, e=e@entry=0x55dd34321ae0, existing_objectclasses=existing_objectclasses@entry=0x0, ldap_uid=ldap_uid@entry=0x0) at /usr/src/debug/evolution-data-server-3.26.3-1.fc27.x86_64/src/addressbook/backends/ldap/e-book-backend-ldap.c:4051
        j = <optimized out>
        cn_values = <optimized out>
        grpattrs = {0x7f5a15ec3b2d "cn", 0x7f5a15ec3f41 "mail", 0x0}
        view_limit = <optimized out>
        count = 137
        book_view = 0x0
        ldap_error = <optimized out>
        result = 0x0
        email_values = <optimized out>
        member_info = 0x55dd38a8eea0
        i = 4
        info = 0x7f5a160c90e0 <prop_info+224>
        values = <optimized out>
        contact = 0x55dd34320050
        dn = <optimized out>
        attr = 0x55dd3431f870 "member"
        ber = 0x55dd3431f7d0
#8  0x00007f5a15ebe18f in generate_cache_handler (op=0x7f5a28162ec0, res=<optimized out>) at /usr/src/debug/evolution-data-server-3.26.3-1.fc27.x86_64/src/addressbook/backends/ldap/e-book-backend-ldap.c:4519
        contact = <optimized out>
        contact_list_op = 0x7f5a28162ec0
        bl = 0x55dd326783d0
        e = 0x55dd34321ae0
        msg_type = <optimized out>
        book_view = 0x0
        start = {tv_sec = 94408551818368, tv_usec = 94408551826272}
        end = {tv_sec = 0, tv_usec = -3855663641352994048}
        diff = <optimized out>
#9  0x00007f5a15ebe51e in poll_ldap (user_data=user_data@entry=0x55dd326783d0) at /usr/src/debug/evolution-data-server-3.26.3-1.fc27.x86_64/src/addressbook/backends/ldap/e-book-backend-ldap.c:4176

Created commit f6d2f340a in eds master (3.27.4+) [1]
Created commit 915b14e5d in eds gnome-3-26 (3.26.4+)

[1] https://git.gnome.org/browse/evolution-data-server/commit/?id=f6d2f340a

(In reply to Milan Crha from comment #12)
> Thanks for a bug report. If I read the backtrace properly, the one of your
> LDAP address books decided to populate/refresh its cache, but it wasn't
> connected, which led to the crash, due to assert of "ld != NULL" in LDAP's
> ldap_pvt_search() function.
> 
> I guess it begun the local cache update when it had been connected (there's
> a code to not start cache update when it's not connected), but during the
> update the backend disconnected, which led to the crash due to insufficient
> checking of the connected state.

VPN had been disconnected for some time, but the laptop had been suspended at that point so it might have started before suspend when the VPN was up, but didn't notice the change properly once it resumed.

*** Bug 1537722 has been marked as a duplicate of this bug. ***

The bug #1537722 was filled with eds 3.26.4, which proves the change from
comment #13 was not enough. Looking closely into the place of the crash I see where I made a mistake, there had been two. Fixed for the next release.

Created commit d8f5e9bfc in eds master (3.27.90+) [2]
Created commit 332da1091 in eds gnome-3-26 (3.26.5+)

[2] https://git.gnome.org/browse/evolution-data-server/commit/?id=d8f5e9bfc