Bug 1029483

Summary: [abrt] evolution-data-server-3.8.5-5.fc19: get_dn_attribute_name: Process /usr/libexec/evolution-addressbook-factory was killed by signal 11 (SIGSEGV)
Product: [Fedora] Fedora Reporter: Brian J. Murrell <brian>
Component: evolution-data-serverAssignee: Matthew Barnes <mbarnes>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: brian, mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:3101b53824f2138712f37b55048ab872211ffe87
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-15 18:45:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
File: backtrace
none
File: cgroup
none
File: core_backtrace
none
File: dso_list
none
File: environ
none
File: exploitable
none
File: limits
none
File: maps
none
File: open_fds
none
File: proc_pid_status none

Description Brian J. Murrell 2013-11-12 13:11:01 UTC 
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
Comment 1 Brian J. Murrell 2013-11-12 13:11:05 UTC 
Created attachment 822961 [details]
File: backtrace
Comment 2 Brian J. Murrell 2013-11-12 13:11:08 UTC 
Created attachment 822962 [details]
File: cgroup
Comment 3 Brian J. Murrell 2013-11-12 13:11:12 UTC 
Created attachment 822963 [details]
File: core_backtrace
Comment 4 Brian J. Murrell 2013-11-12 13:11:15 UTC 
Created attachment 822964 [details]
File: dso_list
Comment 5 Brian J. Murrell 2013-11-12 13:11:18 UTC 
Created attachment 822965 [details]
File: environ
Comment 6 Brian J. Murrell 2013-11-12 13:11:21 UTC 
Created attachment 822966 [details]
File: exploitable
Comment 7 Brian J. Murrell 2013-11-12 13:11:24 UTC 
Created attachment 822967 [details]
File: limits
Comment 8 Brian J. Murrell 2013-11-12 13:11:28 UTC 
Created attachment 822968 [details]
File: maps
Comment 9 Brian J. Murrell 2013-11-12 13:11:34 UTC 
Created attachment 822969 [details]
File: open_fds
Comment 10 Brian J. Murrell 2013-11-12 13:11:38 UTC 
Created attachment 822970 [details]
File: proc_pid_status
Comment 11 Milan Crha 2013-11-13 11:50:15 UTC 
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?
Comment 12 Brian J. Murrell 2013-11-13 12:43:38 UTC 
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.
Comment 13 Milan Crha 2013-11-15 18:45:50 UTC 
(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.
Comment 14 Brian J. Murrell 2013-11-18 04:56:43 UTC 
(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.
Comment 15 Milan Crha 2013-11-18 07:19:02 UTC 
(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).