#47839 389-ds production segfault: __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:144
Closed: wontfix None Opened 8 years ago by nhosoi.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1113022

Created attachment 912004
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
144             movzbl  (%rsi), %eax

#0  __memcpy_sse2_unaligned () at
#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
#3  0x00007fbf94e74c31 in ber_bvcpy (bvs=0x7fbf66ff3b20, bvd=0x7fbf54012cc0) at
#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
#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
#8  0x00007fbf94e758f5 in valuearray_init_bervalarray
(bvals=bvals@entry=0x7fbf66ff3b30, cvals=cvals@entry=0x7fbf66ff39d0) at
#9  0x00007fbf94e0d6f1 in slapi_entry_add_values (e=e@entry=0x7fbf54012ba0,
type=0x7fbf87b9371d "changes", vals=vals@entry=0x7fbf66ff3b30) at
#10 0x00007fbf87b91c48 in modrdn2reple (newsuperior=0x0, ldm=0x7fbf5400b520,
deloldrdn=0, newrdn=0x7fbf5401c9c0
e=0x7fbf54012ba0) at ldap/servers/plugins/retrocl/retrocl_po.c:546
#11 write_replog_db (newsuperior=0x0, modrdn_mods=0x7fbf5400b520,
"idnsName=maddy+nsuniqueid=773ba311-e91c11e3-9cf8e4c9-853fe36c", log_e=0x0,
curtime=1403656344, flag=0, log_m=0x0, dn=0x7fbf54005c70 "idnsName=maddy,idnsna
optype=<optimized out>, pb=<optimized out>) at
#12 retrocl_postob (pb=<optimized out>, optype=<optimized out>) at
#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
#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
#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
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
#22 0x00007fbf8906c6fb in urp_add_operation (pb=pb@entry=0x7fbf66ffcae0) at
#23 0x00007fbf890548e8 in multimaster_bepreop_add (pb=0x7fbf66ffcae0) at
#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
#28 0x00007fbf94df241a in op_shared_add (pb=pb@entry=0x7fbf66ffcae0) at
#29 0x00007fbf94df3750 in do_add (pb=pb@entry=0x7fbf66ffcae0) at
#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
#33 0x00007fbf92bbbf33 in start_thread (arg=0x7fbf66ffd700) at
#34 0x00007fbf928e9ded in clone () at

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):

How reproducible:
Always (with my dataset)

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

Bug description: modrdn2reple (retrocl_po.c) sets the given mods
to the changelog entry with "changes" attribute type if it includes
modifiersname, modifytimestamp, creatorsname, createtimestamp. When
the modrdn is internally initiated and passed mods do not include
the attributes (modifiersname, etc.), make_changes_string returns
empty lenstr. There were 2 issues:
1) there was nothing to add if lenstr was empty, but it was added.
2) there was a bug to set the length +1 even though the length was 0.

Fix description:
1) If there is nothing to add to the change attribute, skip calling
2) Remove adding "+1" for '\0' from the value length: val.bv_len.

Reviewed by Rich (Thank you!!)

Pushed to master:
6e175e3..46a3269 master -> master
commit 46a3269

Pushed to 389-ds-base-1.3.2:
43c85c5..a82c409 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit a82c409

2) Remove adding "+1" for '\0' from the value length: val.bv_len.

Are you sure to remove the +1 if len>0 ?
In my understanding make_changes_string() allocates the terminating null char, but doesn't count it in len - or is ls_buf never handled as string ?

Replying to [comment:6 lkrispen]:

2) Remove adding "+1" for '\0' from the value length: val.bv_len.

Are you sure to remove the +1 if len>0 ?
In my understanding make_changes_string() allocates the terminating null char, but doesn't count it in len - or is ls_buf never handled as string ?

Hi Ludwig, thanks for your comment. I ran the modrdn tests with the mods to modify via valgrind and see no Invalid read/write and no memory leaks.

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone:

6 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1170

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.