Bug 1118069

Summary:	389-ds production segfault: __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:144
Product:	Red Hat Enterprise Linux 7	Reporter:	Noriko Hosoi <nhosoi>
Component:	389-ds-base	Assignee:	Noriko Hosoi <nhosoi>
Status:	CLOSED ERRATA	QA Contact:	Viktor Ashirov <vashirov>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	7.0	CC:	amsharma, nkinder, rmeggins
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	389-ds-base-1.3.3.1-1.el7	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-05 09:36:21 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Noriko Hosoi 2014-07-09 23:21:22 UTC

This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/47839

Ticket was cloned from Red Hat Bugzilla (product ''Fedora''): [https://bugzilla.redhat.com/show_bug.cgi?id=1113022 Bug 1113022]

{{{
Created attachment 912004 [details]
thread apply all bt full stacktrace extract

Description of problem:
389-ds-base in a freeipa multimaster replica is segfaulting. The host with the
issue is attempting to replicate from the other master. The bt is listed as:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:144
144             movzbl  (%rsi), %eax


#0  __memcpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:144
#1  0x00007fbf94e74a1e in memcpy (__len=1, __src=<optimized out>,
__dest=<optimized out>) at /usr/include/bits/string3.h:51
#2  ber_bvcpy (bvd=bvd@entry=0x7fbf54012cc0, bvs=bvs@entry=0x7fbf66ff3b20) at
ldap/servers/slapd/value.c:75
#3  0x00007fbf94e74c31 in ber_bvcpy (bvs=0x7fbf66ff3b20, bvd=0x7fbf54012cc0) at
ldap/servers/slapd/value.c:359
#4  slapi_value_set_berval (value=value@entry=0x7fbf54012cc0,
bval=bval@entry=0x7fbf66ff3b20) at ldap/servers/slapd/value.c:361
#5  0x00007fbf94e74c86 in value_init (v=v@entry=0x7fbf54012cc0,
bval=bval@entry=0x7fbf66ff3b20, t=t@entry=1 '\001', csn=csn@entry=0x0) at
ldap/servers/slapd/value.c:207
#6  0x00007fbf94e74ce2 in value_new (bval=0x7fbf66ff3b20, t=t@entry=1 '\001',
csn=csn@entry=0x0) at ldap/servers/slapd/value.c:184
#7  0x00007fbf94e74d2c in slapi_value_new_berval (bval=<optimized out>) at
ldap/servers/slapd/value.c:116
#8  0x00007fbf94e758f5 in valuearray_init_bervalarray
(bvals=bvals@entry=0x7fbf66ff3b30, cvals=cvals@entry=0x7fbf66ff39d0) at
ldap/servers/slapd/valueset.c:251
#9  0x00007fbf94e0d6f1 in slapi_entry_add_values (e=e@entry=0x7fbf54012ba0,
type=0x7fbf87b9371d "changes", vals=vals@entry=0x7fbf66ff3b30) at
ldap/servers/slapd/entry.c:3660
#10 0x00007fbf87b91c48 in modrdn2reple (newsuperior=0x0, ldm=0x7fbf5400b520,
deloldrdn=0, newrdn=0x7fbf5401c9c0
"idnsName=maddy+nsuniqueid=773ba311-e91c11e3-9cf8e4c9-853fe36c",
e=0x7fbf54012ba0) at ldap/servers/plugins/retrocl/retrocl_po.c:546
#11 write_replog_db (newsuperior=0x0, modrdn_mods=0x7fbf5400b520,
newrdn=0x7fbf5401c9c0
"idnsName=maddy+nsuniqueid=773ba311-e91c11e3-9cf8e4c9-853fe36c", log_e=0x0,
curtime=1403656344, flag=0, log_m=0x0, dn=0x7fbf54005c70 "idnsName=maddy,idnsna
me=ipa.blackhats.net.au,cn=dns,dc=ipa,dc=blackhats,dc=net,dc=au",
optype=<optimized out>, pb=<optimized out>) at
ldap/servers/plugins/retrocl/retrocl_po.c:339
#12 retrocl_postob (pb=<optimized out>, optype=<optimized out>) at
ldap/servers/plugins/retrocl/retrocl_po.c:668
#13 0x00007fbf94e47095 in plugin_call_func (list=0x7fbf96092d10,
operation=operation@entry=562, pb=pb@entry=0x7fbf54012840,
call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:1489
#14 0x00007fbf94e47248 in plugin_call_list (pb=0x7fbf54012840, operation=562,
list=<optimized out>) at ldap/servers/slapd/plugin.c:1451
#15 plugin_call_plugins (pb=pb@entry=0x7fbf54012840,
whichfunction=whichfunction@entry=562) at ldap/servers/slapd/plugin.c:413
#16 0x00007fbf89314f4d in ldbm_back_modrdn (pb=<optimized out>) at
ldap/servers/slapd/back-ldbm/ldbm_modrdn.c:1117
#17 0x00007fbf94e393e7 in op_shared_rename (pb=pb@entry=0x7fbf54012840,
passin_args=0) at ldap/servers/slapd/modrdn.c:652
#18 0x00007fbf94e395c5 in rename_internal_pb (pb=pb@entry=0x7fbf54012840) at
ldap/servers/slapd/modrdn.c:392
#19 0x00007fbf94e39d1a in slapi_modrdn_internal_pb (pb=pb@entry=0x7fbf54012840)
at ldap/servers/slapd/modrdn.c:330
#20 0x00007fbf8906b7c9 in urp_fixup_rename_entry
(entry=entry@entry=0x7fbf5402a780, newrdn=0x7fbf5401c190
"idnsName=maddy+nsuniqueid=773ba311-e91c11e3-9cf8e4c9-853fe36c",
opflags=opflags@entry=0) at ldap/servers/plugins/replication/urp.c:843
#21 0x00007fbf8906bbba in urp_annotate_dn
(sessionid=sessionid@entry=0x7fbf66ff6410 "conn=7 op=6
csn=53783f00000000040000", entry=0x7fbf5402a780, opcsn=0x7fbf54004ec0,
optype=optype@entry=0x7fbf89096083 "ADD") at
ldap/servers/plugins/replication/urp.c:1041
#22 0x00007fbf8906c6fb in urp_add_operation (pb=pb@entry=0x7fbf66ffcae0) at
ldap/servers/plugins/replication/urp.c:253
#23 0x00007fbf890548e8 in multimaster_bepreop_add (pb=0x7fbf66ffcae0) at
ldap/servers/plugins/replication/repl5_plugins.c:755
#24 0x00007fbf94e47095 in plugin_call_func (list=0x7fbf9607a030,
operation=operation@entry=450, pb=pb@entry=0x7fbf66ffcae0,
call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:1489
#25 0x00007fbf94e47248 in plugin_call_list (pb=0x7fbf66ffcae0, operation=450,
list=<optimized out>) at ldap/servers/slapd/plugin.c:1451
#26 plugin_call_plugins (pb=pb@entry=0x7fbf66ffcae0,
whichfunction=whichfunction@entry=450) at ldap/servers/slapd/plugin.c:413
#27 0x00007fbf892f8aaf in ldbm_back_add (pb=0x7fbf66ffcae0) at
ldap/servers/slapd/back-ldbm/ldbm_add.c:336
#28 0x00007fbf94df241a in op_shared_add (pb=pb@entry=0x7fbf66ffcae0) at
ldap/servers/slapd/add.c:735
#29 0x00007fbf94df3750 in do_add (pb=pb@entry=0x7fbf66ffcae0) at
ldap/servers/slapd/add.c:258
#30 0x00007fbf9530aca4 in connection_dispatch_operation (pb=0x7fbf66ffcae0,
op=0x7fbf961fece0, conn=0x7fbf800cb410) at ldap/servers/slapd/connection.c:645
#31 connection_threadmain () at ldap/servers/slapd/connection.c:2534
#32 0x00007fbf9321be5b in _pt_root (arg=0x7fbf961f74d0) at
../../../nspr/pr/src/pthreads/ptthread.c:212
#33 0x00007fbf92bbbf33 in start_thread (arg=0x7fbf66ffd700) at
pthread_create.c:309
#34 0x00007fbf928e9ded in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111

As per http://directory.fedoraproject.org/wiki/FAQ#Debugging_Crashes I have
attached a full stacktrace relating to this thread. If needed I can provide the
coredump as well.

Version-Release number of selected component (if applicable):
1.3.2.16-1.fc20.x86_64

How reproducible:
Always (with my dataset)

Steps to Reproduce:
1. Start up 389-ds
2. Trigger a replication
3. Wait
}}}

Comment 1 Noriko Hosoi 2014-07-09 23:24:24 UTC

Hard to reproduce the problem.
IPA + MMR + replication conflict, then running consumer initialization makes the server crash.
Fix was verified at the customer site.
Sanity check only?

Comment 3 Amita Sharma 2014-12-18 14:05:14 UTC

Based on comment https://bugzilla.redhat.com/show_bug.cgi?id=1118069#c1
I have verified MMR functions well with latest build.
Marking bug as VERIFIED.

Comment 5 errata-xmlrpc 2015-03-05 09:36:21 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-0416.html