Created attachment 1120259 [details]
customer custom schema

Upstream ticket:
https://fedorahosted.org/389/ticket/48492

> The value of DESC contains a non-ascii character.  According to the RFC, the value is supposed to be utf8, but it's not clear to me if it is a UTF8 string or not.

It is not utf8.  \341 is not a utf8 character.
(gdb) print (unsigned char)'\341'
$1 = 225 '\341'

The proper utf8 representation of this character should have 2 bytes.  Looks like this character is iso8859:

       341   225   E1     á     LATIN SMALL LETTER A WITH ACUTE

This is usually the sort of thing that syntax checking catches.  For example, if attributetypes has DirectoryString syntax, this value should be rejected.  I don't know if we do syntax checking on schema values.

Created attachment 1141350 [details]
valgrind report

To reproduce crash with Custom schema replication.

1). Installed 389-ds-base-1.3.5.10-11 on RHEL7.3 latest RTT.

2). Created a working 2 Master and 2 Consumer replication setup.

3). Tested synchronization between Masters/Consumers.

4). Followed the steps given in comemnt #59 and #79 to reproduce the crash.

[root@ratangad slapd-M1]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  -b "cn=config" |grep -i syntaxcheck
nsslapd-syntaxcheck: off

[root@ratangad slapd-M1]# ldapsearch -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  -b "cn=config" |grep -i nsslapd-enquote-sup-oc
nsslapd-enquote-sup-oc: on

[root@ratangad slapd-M1]# cat /export/Backups/99deref_schema.ldif dn: cn=schema
attributeTypes: ( NAME 'testRunDerefUser' DESC 'Attribute DerefControl tests Multi-Valued' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
objectClasses: ( NAME 'testderefperson' SUP top STRUCTURAL MUST ( sn $ cn $ l $ testRunDerefUser )
        MAY ( userPassword $ seeAlso $ description ) X-ORIGIN 'DerefControlTest' )

[root@ratangad slapd-M1]# /usr/lib64/dirsrv/slapd-M1/stop-slapd  ; sleep 2 ; cp /export/Backups/99deref_schema.ldif /etc/dirsrv/slapd-M1/schema/

[root@ratangad slapd-M1]# /usr/lib64/dirsrv/slapd-M1/start-slapd  

[root@ratangad slapd-M1]# ./schema-reload.pl -v -Z slapd-M1 -D "cn=Directory Manager" -w Secret123 -d /etc/dirsrv/slapd-M1/schema/ldap_initialize( ldap://ratangad.eng.blr.redhat.com:1189 )
Successfully added task entry "cn=schema_reload_2016_9_23_18_16_37, cn=schema reload task, cn=tasks, cn=config"

[root@ratangad slapd-M1]# tail -f /var/log/dirsrv/slapd-M1/errors 
[23/Sep/2016:18:14:01.828640388 +051800] schemareload - Schema validation passed.
[23/Sep/2016:18:14:01.877523305 +051800] schemareload - Schema reload task finished.
[23/Sep/2016:18:16:37.041087640 +051800] schemareload - Schema reload task starts (schema dir: /etc/dirsrv/slapd-M1/schema/) ...
[23/Sep/2016:18:16:37.099379033 +051800] schemareload - Schema validation passed.
[23/Sep/2016:18:16:37.149524557 +051800] schemareload - Schema reload task finished.

5). Created/modified few entries in M1 to make the schema replicated to other masters and consumers.
[root@ratangad MMR_WINSYNC]# ./AddEntry.sh Users 1189 "ou=testing,dc=passsync,dc=com" derefusr 99 localhost > /dev/null
[root@ratangad MMR_WINSYNC]# PORT=1189; SUFF="dc=passsync,dc=com"; for PORT in `echo "1189 1289 1389 1489 "`; do /usr/bin/ldapsearch -x -p $PORT -h localhost -D "cn=Directory Manager" -w Secret123 -b $SUFF |grep -i dn: | wc -l ; done
15783
15783
15783
15783

[root@ratangad MMR_WINSYNC]# ldapmodify -D "cn=Directory Manager" -w Secret123 -h localhost -p 1189 -x  << EOFdn: uid=derefusr32,ou=Testing,dc=passsync,dc=com                                                                                             replace: userPassword
userPassword: Secret123
EOF

modifying entry "uid=derefusr32,ou=Testing,dc=passsync,dc=com"

[root@ratangad MMR_WINSYNC]# PORT=1389; SUFF="dc=passsync,dc=com"; PORT=1189 ;  /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "abcdefhijklmnopqrstuvwxyzabcdefhijklmnopqrstuvwxyz" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?
ldap_bind: Invalid credentials (49)
49
[root@ratangad MMR_WINSYNC]# PORT=1389; SUFF="dc=passsync,dc=com"; PORT=1189 ;  /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "Secret123" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?0
[root@ratangad MMR_WINSYNC]# PORT=1289; SUFF="dc=passsync,dc=com"; PORT=1189 ;  /usr/bin/ldapsearch -x -p $PORT -h localhost -D "uid=derefusr32,ou=Testing,dc=passsync,dc=com" -w "Secret123" -b "uid=derefusr32,ou=Testing,dc=passsync,dc=com" > /dev/null ; echo $?
0


6). [root@ratangad MMR_WINSYNC]# ls /var/spool/abrt
last-ccpp  last-via-server

No crashes observed. Also, no issues with syncing entries after schema replication. 

Hence, marking the bug as Verified.

[root@ratangad MMR_WINSYNC]# rpm -qa |grep -i 389-ds-base
389-ds-base-snmp-1.3.5.10-11.el7.x86_64
389-ds-base-libs-1.3.5.10-11.el7.x86_64
389-ds-base-debuginfo-1.3.5.10-6.el7.x86_64
389-ds-base-1.3.5.10-11.el7.x86_64
389-ds-base-devel-1.3.5.10-11.el7.x86_64

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-2016-2594.html