Hide Forgot
Version-Release number of selected component: evolution-data-server-3.8.5-5.fc19 Additional info: reporter: libreport-2.1.8 backtrace_rating: 4 cmdline: /usr/libexec/evolution-addressbook-factory crash_function: get_dn_attribute_name executable: /usr/libexec/evolution-addressbook-factory kernel: 3.11.6-200.fc19.x86_64 runlevel: N 5 type: CCpp uid: 1001 var_log_messages: Nov 8 17:46:31 pc abrt[6276]: Saved core dump of pid 27142 (/usr/libexec/evolution-addressbook-factory) to /var/tmp/abrt/ccpp-2013-11-08-17:46:29-27142 (87478272 bytes) Truncated backtrace: Thread no. 1 (5 frames) #0 get_dn_attribute_name at e-book-backend-ldap.c:1249 #1 create_dn_from_contact at e-book-backend-ldap.c:1285 #2 e_book_backend_ldap_create_contacts at e-book-backend-ldap.c:1711 #3 operation_thread at e-data-book.c:609 #5 g_thread_proxy at gthread.c:798
Created attachment 822961 [details] File: backtrace
Created attachment 822962 [details] File: cgroup
Created attachment 822963 [details] File: core_backtrace
Created attachment 822964 [details] File: dso_list
Created attachment 822965 [details] File: environ
Created attachment 822966 [details] File: exploitable
Created attachment 822967 [details] File: limits
Created attachment 822968 [details] File: maps
Created attachment 822969 [details] File: open_fds
Created attachment 822970 [details] File: proc_pid_status
Thanks for a bug report. I see that you tried to create a new contact in an LDAP addressbook, but it failed due to some limitations? Could you provide more details about this, please? I'm especially interested in the offending contact, or any test contact, which would reproduce the crash. Also, is the LDAP book really writeable, or it's readonly and you chose it by an accident? What login type do you use to connect to the server?
So yeah. Had a bit of difficulty actually getting a new LDAP addressbook to work. This crash was part of that effort. All along I was trying to use the same addressbook, although I was probably experimenting with login types doing it. I ended up using DN, but even though you didn't ask, I will tell you that I would have preferred to have used GSSAPI as that is supported at this site. :-) So a number of Evolution restarts (it would be nice if Evolution was more flexible in the area of trying to reconnect to LDAP servers when connection details are changed but it seems one really ends up having to simply restart when one changes an LDAP addressbook configuration) and it finally ended up working. I'm afraid I don't think I know much more than that. There wasn't any one particular offending contact add that caused this that I think would reproduce it. It was simply poking away at it trying to get Evolution to work with it. A process which could much more smooth, but it is what it is.
(In reply to Brian J. Murrell from comment #12) > I ended up using DN, but even though you didn't ask, I will tell you that I > would have preferred to have used GSSAPI as that is supported at this site. Yeah, I found a quite old upstream request to add support for it: https://bugzilla.gnome.org/show_bug.cgi?id=266506 > So a number of Evolution restarts (it would be nice if Evolution was more > flexible in the area of trying to reconnect to LDAP servers when connection > details are changed but it seems one really ends up having to simply restart > when one changes an LDAP addressbook configuration) and it finally ended up > working. Oh, right, the process to restart is evolution-addressbook-factory, which takes care of connection to respective books. > I'm afraid I don't think I know much more than that. There wasn't any one > particular offending contact add that caused this that I think would > reproduce it. It was simply poking away at it trying to get Evolution to > work with it. A process which could much more smooth, but it is what it is. Hmm, okay, in that case I hope you'll be fine if I just close this. Maybe someone in the future will find any steps to reproduce it and then it'll be eventually properly fixed upstream.
(In reply to Milan Crha from comment #13) > > Yeah, I found a quite old upstream request to add support for it: > https://bugzilla.gnome.org/show_bug.cgi?id=266506 Yeah, _really_ old. Any chance of updating Version on it and any other particulars to keep it relevant? > Oh, right, the process to restart is evolution-addressbook-factory, which > takes care of connection to respective books. And I can restart (kill?) that while evolution is running and evolution will (restart and?) reconnect to it? > Hmm, okay, in that case I hope you'll be fine if I just close this. Maybe > someone in the future will find any steps to reproduce it and then it'll be > eventually properly fixed upstream. Sure.
(In reply to Brian J. Murrell from comment #14) > Yeah, _really_ old. Any chance of updating Version on it and any other > particulars to keep it relevant? It can be done, but at least the version doesn't matter that much. For reports like that the version is more like "it was found with version X", rather than whether it's still relevant in current supported version; at least for me. You can always add comments there. > And I can restart (kill?) that while evolution is running and evolution will > (restart and?) reconnect to it? It partly will, but the safest is to close all evolution processes, with calendar factory as the last (because gnome-shell, if you run it, tends to start it on its own, which can start other evolution processes as well).