Bug 474248 - Replica crashes in the consumer initialization if the backend to be replicated does not exist
Replica crashes in the consumer initialization if the backend to be replicate...
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Replication - General (Show other bugs)
1.1.3
All Linux
low Severity medium
: ---
: ---
Assigned To: Noriko Hosoi
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2008-12-02 17:59 EST by Noriko Hosoi
Modified: 2015-01-04 18:35 EST (History)
3 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:08:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
cvs diff slapd/mapping_tree.c plugins/replication/repl_extop.c plugins/replication/replutil.c (3.58 KB, patch)
2008-12-02 18:35 EST, Noriko Hosoi
no flags Details | Diff
cvs commit message (1.24 KB, text/plain)
2008-12-03 19:43 EST, Noriko Hosoi
no flags Details
ldif file used to populate dc=sub,dc=example,dc=com on the consumer before replication. (147.98 KB, application/octet-stream)
2009-04-07 17:49 EDT, Michael Gregg
no flags Details

  None (edit)
Description Noriko Hosoi 2008-12-02 17:59:46 EST
Steps to reproduce the problem
1. Set up replication (I used single master - single replica)
   Both have the suffix "dc=example,dc=com"
2. Create a sub suffix ou=sub,dc=example,dc=com only on master
3. Create an agreement to replicate ou=sub,dc=example,dc=com
4. Initialize the replica, which crashes the replica

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x438c1950 (LWP 27456)]
0x0000003c1c880f80 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x0000003c1c880f80 in strlen () from /lib64/libc.so.6
#1  0x00000000006d3afe in slapi_mtn_set_state (sdn=0x1d62680, state=0x0)
    at ldap/servers/slapd/mapping_tree.c:3059
#2  0x00007f2c42084965 in repl_set_mtn_state_and_referrals (
    repl_root_sdn=0x1d62680, mtn_state=0x0, ruv=0x0, ruv_referrals=0x0,
    other_referrals=0x0) at ldap/servers/plugins/replication/replutil.c:764
#3  0x00007f2c42062495 in multimaster_extop_StartNSDS50ReplicationRequest (
    pb=0x1de1c20) at ldap/servers/plugins/replication/repl_extop.c:841
#4  0x00000000006e2211 in plugin_call_exop_plugins (pb=0x1de1c20, 
    oid=0x1c26eb0 "2.16.840.1.113730.3.5.3") at ldap/servers/slapd/plugin.c:393
#5  0x000000000041a453 in do_extended (pb=0x1de1c20)
    at ldap/servers/slapd/extendop.c:300
#6  0x00000000004127f3 in connection_dispatch_operation (conn=0x7f2c3f587728, 
    op=0x1de60d0, pb=0x1de1c20) at ldap/servers/slapd/connection.c:560
#7  0x0000000000413d18 in connection_threadmain ()
    at ldap/servers/slapd/connection.c:2161
#8  0x0000003c2c429aa3 in ?? () from /usr/lib64/libnspr4.so
#9  0x0000003c1d40729a in start_thread (arg=<value optimized out>)
    at pthread_create.c:297
#10 0x0000003c1c8e439d in clone () from /lib64/libc.so.6

Cause of the crase:
In the following code, slapi_mtn_get_state returns NULL since the mapping tree entry 'cn="ou=sub,dc=example,dc=com",cn=mapping tree,cn=config' does not exist on the Replica.  At the line 835, slapi_start_bulk_import fails due to the same reason.  In the error handling code, it tries to set the original state back even though the state does not exist.  We should skip resetting the mapping tree state.
(repl_extop.c)
 533 /*
 534  * This plugin entry point is called whenever a
 535  * StartNSDS50ReplicationRequest is received.
 536  */
 537 int
 538 multimaster_extop_StartNSDS50ReplicationRequest(Slapi_PBlock *pb)
 539 {
    [...]
 813     {
 814         char *mtnstate = slapi_mtn_get_state(repl_root_sdn);
 815         char **mtnreferral = slapi_mtn_get_referral(repl_root_sdn);
 816 
    [...]
 833         /* start the bulk import */
 834         slapi_pblock_set (pb, SLAPI_TARGET_DN, repl_root);
 835         rc = slapi_start_bulk_import (pb);
 836         if (rc != LDAP_SUCCESS)
 837         {
 838             response = NSDS50_REPL_INTERNAL_ERROR;
 839             /* reset the mapping tree state to what it was before
 840                we tried to do the bulk import */
 841             repl_set_mtn_state_and_referrals(repl_root_sdn, mtnstate,
 842                                              NULL, NULL, mtnreferral);
Comment 1 Noriko Hosoi 2008-12-02 18:35:21 EST
Created attachment 325451 [details]
cvs diff slapd/mapping_tree.c plugins/replication/repl_extop.c plugins/replication/replutil.c

Files:
  ldap/servers/slapd/mapping_tree.c
  ldap/servers/plugins/replication/repl_extop.c
  ldap/servers/plugins/replication/replutil.c

Description:
  . mapping_tree.c: if NULL mapping tree state is passed, return an error.
  . repl_extop.c: if mapping tree node state is NULL, don't reset the mapping
                  tree state.
  . replutil.c: if NULL mapping tree state is passed, log it and return.
Comment 2 Noriko Hosoi 2008-12-03 19:43:41 EST
Created attachment 325616 [details]
cvs commit message

Reviewed by Nathan (Thank you!!)

Checked in into CVS HEAD.
Comment 3 Michael Gregg 2009-04-07 17:46:18 EDT
Using the attached ldif file to initialize the consumer with backend done succeeded.

Completed with the following entry in the error log:
[07/Apr/2009:14:42:59 -0700] NSMMReplicationPlugin - agmt="cn=sub" (praseodymium:3660): Simple bind failed, LDAP sdk error 91 (Can't connect to the LDAP server), Netscape Portable Runtime error -5961 (TCP connection reset by peer.)

verified
Comment 4 Michael Gregg 2009-04-07 17:49:18 EDT
Created attachment 338616 [details]
ldif file used to populate dc=sub,dc=example,dc=com on the consumer before replication. 

Not that this file is really necessary, but it's probably nice to have.
Comment 5 Chandrasekar Kannan 2009-04-29 19:08:22 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

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