Bug 634561 - Server crushes when using Windows Sync Agreement
Summary: Server crushes when using Windows Sync Agreement
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Replication - General
Version: 1.2.6
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
: 636682 (view as bug list)
Depends On:
Blocks: 389_1.2.6 639035
TreeView+ depends on / blocked
 
Reported: 2010-09-16 11:19 UTC by serejka
Modified: 2015-12-07 16:54 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:54:03 UTC


Attachments (Terms of Use)
output of bt full (1.54 KB, text/x-log)
2010-09-16 16:02 UTC, serejka
no flags Details
output thread apply all bt full (51.74 KB, text/x-log)
2010-09-16 16:03 UTC, serejka
no flags Details
0001-Bug-634561-Server-crushes-when-using-Windows-Sync.patch (6.51 KB, patch)
2010-09-22 22:30 UTC, Rich Megginson
nhosoi: review+
Details | Diff

Description serejka 2010-09-16 11:19:04 UTC
Description of problem:
When we create replication agreement between DS server and windows Active Directory (Windows 2003 R2 x64 with Identity Management for UNIX) and make "Initiate Full Re-syncronization" DS crushes with segfault. Also we are not able to remove this replication agreement because of the same error.

Version-Release number of selected component (if applicable):
389-ds-base version 1.2.6


Steps to Reproduce:
1. Install DS packages via metapackage "389-ds"
2. Enable replication opportunities
3. Create replication agreement between AD and DS
4. Start "Initiate Full Re-syncronization"
  
Actual results:
DS server crushes with segfault

Expected results:
Resyncronization should be finished correctly without any crush.

Additional info:
[Switching to Thread 0x44f51940 (LWP 3619)]
0x00002ac67789f950 in pthread_mutex_lock () from /lib64/libpthread.so.0
(gdb) bt
#0  0x00002ac67789f950 in pthread_mutex_lock () from /lib64/libpthread.so.0
#1  0x00002ac677261959 in PR_Lock () from /usr/lib64/libnspr4.so
#2  0x00002ac67e73d120 in conn_cancel_linger () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so
#3  0x00002ac67e75a61e in ?? () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so
#4  0x00002ac67e744334 in ?? () from /usr/lib64/dirsrv/plugins/libreplication-plugin.so
#5  0x00002ac677266f1d in ?? () from /usr/lib64/libnspr4.so
#6  0x00002ac67789d4a7 in start_thread () from /lib64/libpthread.so.0
#7  0x00002ac677b85c2d in clone () from /lib64/libc.so.6


(gdb) info threads
  45 Thread 0x41959940 (LWP 3610)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  44 Thread 0x4274d940 (LWP 3611)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  43 Thread 0x4314e940 (LWP 3612)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  42 Thread 0x43b4f940 (LWP 3613)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  41 Thread 0x44550940 (LWP 3614)  0x00002ac6778a1b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  40 Thread 0x4197a940 (LWP 3615)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  39 Thread 0x4199b940 (LWP 3616)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  38 Thread 0x419bc940 (LWP 3617)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  37 Thread 0x419dd940 (LWP 3618)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
* 36 Thread 0x44f51940 (LWP 3619)  0x00002ac67789f950 in pthread_mutex_lock () from /lib64/libpthread.so.0
  35 Thread 0x45952940 (LWP 3620)  0x00002ac6778a1b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  34 Thread 0x46353940 (LWP 3621)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  33 Thread 0x46d54940 (LWP 3622)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  32 Thread 0x47755940 (LWP 3634)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  31 Thread 0x48156940 (LWP 3635)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  30 Thread 0x48b57940 (LWP 3636)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  29 Thread 0x49558940 (LWP 3637)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  28 Thread 0x49f59940 (LWP 3638)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  27 Thread 0x4a95a940 (LWP 3639)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  26 Thread 0x4b35b940 (LWP 3640)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  25 Thread 0x4bd5c940 (LWP 3641)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  24 Thread 0x4c75d940 (LWP 3642)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  23 Thread 0x4d15e940 (LWP 3643)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  22 Thread 0x4db5f940 (LWP 3644)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  21 Thread 0x4e560940 (LWP 3645)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  20 Thread 0x4ef61940 (LWP 3646)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  19 Thread 0x4f962940 (LWP 3647)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  18 Thread 0x50363940 (LWP 3648)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  17 Thread 0x50d64940 (LWP 3649)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  16 Thread 0x51765940 (LWP 3650)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  15 Thread 0x52166940 (LWP 3651)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  14 Thread 0x52b67940 (LWP 3652)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  13 Thread 0x53568940 (LWP 3653)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  12 Thread 0x53f69940 (LWP 3654)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  11 Thread 0x5496a940 (LWP 3655)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  10 Thread 0x5536b940 (LWP 3656)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  9 Thread 0x55d6c940 (LWP 3657)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  8 Thread 0x5676d940 (LWP 3658)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  7 Thread 0x5716e940 (LWP 3659)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  6 Thread 0x57b6f940 (LWP 3660)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  5 Thread 0x58570940 (LWP 3661)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  4 Thread 0x58f71940 (LWP 3662)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
  3 Thread 0x59972940 (LWP 3663)  0x00002ac6778a1e00 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
  2 Thread 0x5a373940 (LWP 3664)  0x00002ac677b7eed2 in select () from /lib64/libc.so.6
  1 Thread 0x2ac679368530 (LWP 3587)  0x00002ac677b7ce46 in poll () from /lib64/libc.so.6

Comment 1 serejka 2010-09-16 11:20:45 UTC
Sorry forgot to mention:
There is no PassSync installed on windows side. In previos version 1.2.5 this worked fine.

Comment 2 Rich Megginson 2010-09-16 15:11:56 UTC
Can you install the 389-ds-base-debuginfo package, then use gdb and do a "bt full" in the thread that got the seg fault?  Or just do
thread apply all bt full
and attach the output to this bug as an attachment.

Can you also provide more information about your replication/sync configuration so that we can attempt to reproduce this issue?

Comment 3 serejka 2010-09-16 16:02:52 UTC
Created attachment 447781 [details]
output of bt full

Comment 4 serejka 2010-09-16 16:03:29 UTC
Created attachment 447782 [details]
output thread apply all bt full

Comment 5 serejka 2010-09-16 16:29:19 UTC
Ok, here is more info.
Windows side:
1. Windows 2003 R2 Russian with Identity Management for UNIX is installed.
2. Identity managment is configured and every user has Unixes attributes (uid, gid, etc.).
3. Also there is no PassSync utility installed on windows host.

Linux side:
1. Centos 5.4 installed with EPEL repository.
2. Also latest DS packages are installed:
389-adminutil-1.1.8-4.el5
389-ds-console-1.2.3-1.el5
389-ds-base-1.2.6-1.el5
389-console-1.1.4-1.el5
389-ds-base-debuginfo-1.2.6-1.el5
389-dsgw-1.1.5-1.el5
389-admin-console-1.1.5-1.el5
389-ds-console-doc-1.2.3-1.el5
389-admin-1.1.11-1.el5
389-admin-console-doc-1.1.5-1.el5
389-ds-1.2.1-1.el5

3. DS is configured by default. 
4. Create replication manager under "cn=config". 
dn: uid=replman,cn=config
uid: replman
givenName: replication
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
sn: manager
cn: replication manager
userPassword:: e1NTSEF9d1B3ZWJ2QzROTzZWZTlsRVNBYXNjU29SQlg1ajE1ZmZxUXlva1E9PQ=

5. Enable replication by checking "Enable Changelog" and "Use default" path for database directory
6. Enable replication agreement for "userRoot" with follow configuration:
dn: cn=replica,cn=dc\3Dcentosvm,cn=mapping tree,cn=config
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaRoot: dc=centosvm
nsDS5ReplicaType: 3
nsDS5Flags: 1
nsDS5ReplicaId: 1
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaBindDN: uid=replman,cn=config
cn: replica
nsState:: AQAAAAAAAADdP5JMAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAA==
nsDS5ReplicaName: 66dae382-c18011df-a9eeef1d-401e8cfe
nsds5ReplicaChangeCount: 2
nsds5replicareapactive: 0

7. After configuration has passed successfully trying init it via "Initiate full re-syncronization"

After that DS is crashing.

Comment 6 serejka 2010-09-22 12:16:08 UTC
Have you been able to reproduce this issue? Or do I need to provide more information?

Comment 7 Rich Megginson 2010-09-22 22:29:18 UTC
*** Bug 636682 has been marked as a duplicate of this bug. ***

Comment 8 Rich Megginson 2010-09-22 22:30:29 UTC
Created attachment 449061 [details]
0001-Bug-634561-Server-crushes-when-using-Windows-Sync.patch

Comment 9 serejka 2010-09-23 08:14:26 UTC
Ok.
I can confirm this patch fixes the issue. 
We may close this case.

Comment 12 Amita Sharma 2011-05-12 11:05:48 UTC
Tested with below steps:

1. Install DS packages via metapackage "389-ds"
2. Enable replication opportunities
3. Create replication agreement between AD and DS
4. Start "Initiate Full Re-syncronization"

VERIFIED.


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