Bug 1029483 - [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)
[abrt] evolution-data-server-3.8.5-5.fc19: get_dn_attribute_name: Process /us...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: evolution-data-server (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
abrt_hash:3101b53824f2138712f37b55048...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-12 08:11 EST by Brian J. Murrell
Modified: 2013-11-18 02:19 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-15 13:45:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (33.03 KB, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: cgroup (143 bytes, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: core_backtrace (18.12 KB, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: dso_list (17.59 KB, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: environ (1.22 KB, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: exploitable (82 bytes, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: limits (1.29 KB, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: maps (80.23 KB, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: open_fds (750 bytes, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details
File: proc_pid_status (991 bytes, text/plain)
2013-11-12 08:11 EST, Brian J. Murrell
no flags Details

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

Note You need to log in before you can comment on or make changes to this bug.