Hide Forgot
Description of problem: Seems that there's a corrupted syntaxinfo structure at replicating the schema Program terminated with signal 6, Aborted. #0 0x00007f0ce3e3e5f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt #0 0x00007f0ce3e3e5f7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007f0ce3e3fce8 in __GI_abort () at abort.c:90 #2 0x00007f0ce3e7e317 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7f0ce3f879c8 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:196 #3 0x00007f0ce3e85fe1 in malloc_printerr ( ar_ptr=0x7f0ce41c3760 <main_arena>, ptr=<optimized out>, str=0x7f0ce3f850b4 "free(): invalid pointer", action=3) at malloc.c:5013 #4 _int_free (av=0x7f0ce41c3760 <main_arena>, p=<optimized out>, have_lock=0) at malloc.c:3835 #5 0x00007f0ce65fe9c6 in slapi_ch_free (ptr=0x7f0c80075b90) at ldap/servers/slapd/ch_malloc.c:292 #6 0x00007f0ce65fea35 in slapi_ch_free_string (s=<optimized out>) at ldap/servers/slapd/ch_malloc.c:325 #7 0x00007f0ce65f9608 in attr_syntax_free (a=0x7f0c80075b90) at ldap/servers/slapd/attrsyntax.c:195 #8 0x00007f0ce666b6ba in schema_berval_to_atlist ( at_berval=at_berval@entry=0x7f0c80010580) at ldap/servers/slapd/schema.c:7192 #9 0x00007f0ce666cea3 in schema_attributetypes_superset_check ( remote_schema=remote_schema@entry=0x7f0c80010580, type=type@entry=0x7f0cdb6f63e5 "supplier") at ldap/servers/slapd/schema.c:7267 #10 0x00007f0cdb6b28a7 in update_consumer_schema ( conn=conn@entry=0x7f0ce86f6a30) at ldap/servers/plugins/replication/repl5_connection.c:1742 #11 0x00007f0cdb6b39a8 in conn_push_schema (conn=0x7f0ce86f6a30, remotecsn=remotecsn@entry=0x7f0c8f7fdc80) at ldap/servers/plugins/replication/repl5_connection.c:1823 #12 0x00007f0cdb6b5a77 in repl5_inc_run (prp=0x7f0ce86f9870) at ldap/servers/plugins/replication/repl5_inc_protocol.c:973 #13 0x00007f0cdb6bba3c in prot_thread_main (arg=0x7f0ce86a7230) at ldap/servers/plugins/replication/repl5_protocol.c:267 #14 0x00007f0ce48307bb in _pt_root (arg=0x7f0ce87037a0) at ../../../nspr/pr/src/pthreads/ptthread.c:212 #15 0x00007f0ce41d1dc5 in start_thread (arg=0x7f0c8f7fe700) at pthread_create.c:308 #16 0x00007f0ce3eff21d in clone () The problem seems to be when parsing the remote schema rc = parse_at_str(at_berval[i]->bv_val, &at, errorbuf, sizeof (errorbuf), DSE_SCHEMA_NO_CHECK | DSE_SCHEMA_USE_PRIV_SCHEMA, 0, schema_ds4x_compat, 0); if(rc){ attr_syntax_free(at); break; } The structure at_berval seems to be right in the core: (gdb) print at_berval[859]->bv_val $28 = 0x7f0c80073950 "( 2.16.840.1.113730.3.1.612 NAME 'generation' DESC 'Netscape defined attribute type' SYNTAX '1.3.6.1.4.1.1466.115.121.1.26' X-ORIGIN 'Netscape Directory Server' )" (gdb) print at_berval[859] $29 = (struct berval *) 0x7f0c80073a00 (gdb) print at_berval[860] $30 = (struct berval *) 0x0 so, it seems as if while parsing it to get the attribute sintaxis, something is not going on fine. Or the heap corruption could be former to that ? I will try to give further details as possible. Version-Release number of selected component (if applicable): 389-ds-base-1.3.4.0-21.el7_2.x86_64
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