openldap-bugs

openldap-bugs@openldap.org

1 participants
21003 discussions

(ITS#7633) Slapd hangs on hdb write lock
by dusan.fric＠t-systems.sk 26 Jun '13

26 Jun '13

Full_Name: Dusan Fric Version: 2.4.32 OS: RHEL 5.7 x64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.212.40.139) We are experiencing frequent hangs in slapd. Once hung we usualy cannot continue to connect until we kill -9 the slapd process and restart it. The directory is used for 2 applications as user eDir and we are using it in production over 1 month - we have noted the busier the directory becomes the more often it hangs (now twice per week). We have installed identical configurations on 3 environments, each has only one single server (no replication). There are 30k entries in the directory (production). We are running: RHEL 5.7 x64 (VMWare with NFS mountpoints) OpenLDAP 2.4.32 Berkeley DB 4.8.30 (4.7.25) We were starting with DB 4.8.30, after downgrade to version 4.7.25 (according to ITS#7378 - https://www.openldap.org/its/index.cgi/Incoming?id=7378;selectid=7378) we are facing the same issue. The problem occurs when two requests simultaneously try to update attributes of a record and in most cases of the same DN value. We can easily reproduce it with a java test program running 2 threads each connecting to the ldap server and updating the record for a particular DN value. It need not be the same DN value but DN values which reside on the same BDB page. Configuration olc cn=config (part): dn: cn=config objectClass: olcGlobal cn: config olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 32 olc DB hdb config (part): dn: olcDatabase={1}hdb,cn=config objectClass: olcHdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}hdb olcDbCacheSize: 80000 olcDbCheckpoint: 128 5 olcDbConfig: {0}set_cachesize 0 268435456 1 olcDbConfig: {1}set_lg_max 10485760 olcDbConfig: {2}set_lg_bsize 2097152 olcDbConfig: {3}set_lg_dir /pkg/openldap/dblog olcDbConfig: {4}set_lg_regionmax 262144 olcDbConfig: {5}set_lk_detect DB_LOCK_EXPIRE olcDbConfig: {6}set_flags DB_TXN_NOSYNC olcDbDirtyRead: FALSE olcDbDNcacheSize: 0 olcDbIDLcacheSize: 240000 olcDbIndex: default eq,sub olcDbIndex: objectClass eq olcDbIndex: cn eq,sub olcDbIndex: uid eq,sub olcDbIndex: mail pres,eq olcDbIndex: sn eq,sub olcDbIndex: member eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: TRUE olcDbSearchStack: 20 olcDbShmKey: 0 olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: TRUE olcReadOnly: FALSE We have managed to collect db_stat lock information, which indicates the same issue with DB write locks on both DB versions. db_stat -C ol (4.8.30) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID /apps/DECCLASA-1/data/openldap/__db.005 Region name 0x2ab41cdc3000 Region address 0x2ab41cdc3138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 1 READ 1 HELD id2entry.bdb handle 0 2 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 3 dd= 0 locks held 1 write locks 0 pid/thread 30034/47555767609232 3 READ 1 HELD dn2id.bdb handle 0 4 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 5 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 6 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 7 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 8 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 9 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 9 READ 1 HELD objectClass.bdb handle 0 a dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 b dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 c dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 c READ 1 HELD uid.bdb handle 0 d dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 f dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 10 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 10 READ 1 HELD member.bdb handle 0 11 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 12 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 13 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 13 READ 1 HELD mail.bdb handle 0 14 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 15 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 16 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 17 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 18 dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 18 READ 1 HELD sn.bdb handle 0 19 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1a dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1b dd= 0 locks held 1 write locks 0 pid/thread 30034/1147971904 1b READ 1 HELD cn.bdb handle 0 1c dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1d dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 1e dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 1f dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 80000003 dd= 0 locks held 0 write locks 0 pid/thread 30034/47555767609232 80000004 dd= 0 locks held 0 write locks 0 pid/thread 30034/1139579200 80000005 dd= 0 locks held 0 write locks 0 pid/thread 30034/1147971904 80000006 dd= 0 locks held 0 write locks 0 pid/thread 30034/1131186496 80000007 dd= 0 locks held 0 write locks 0 pid/thread 30034/1122793792 80000026 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 80000027 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 80000028 dd= 0 locks held 1 write locks 0 pid/thread 30034/1131186496 80000028 WRITE 1 WAIT mail.bdb page 3 80000028 READ 1 HELD mail.bdb page 3 80000029 dd= 0 locks held 1 write locks 0 pid/thread 30034/1122793792 80000029 WRITE 1 WAIT mail.bdb page 3 80000029 READ 1 HELD mail.bdb page 3 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 80000027 READ 1 HELD 0x36490 len: 9 data: 0x370000000000000000 1b READ 1 HELD cn.bdb handle 0 10 READ 1 HELD member.bdb handle 0 9 READ 1 HELD objectClass.bdb handle 0 c READ 1 HELD uid.bdb handle 0 80000026 READ 1 HELD 0x5e948 len: 9 data: 0x560x0500000000000000 1 READ 1 HELD id2entry.bdb handle 0 18 READ 1 HELD sn.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 80000029 READ 1 HELD mail.bdb page 3 80000028 READ 1 HELD mail.bdb page 3 80000029 WRITE 1 WAIT mail.bdb page 3 80000028 WRITE 1 WAIT mail.bdb page 3 13 READ 1 HELD mail.bdb handle 0 db_stat -C ol (4.7.25) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lock REGINFO information: Lock Region type 5 Region ID /apps/DECCLASA-1/data/openldap/__db.005 Region name 0x2b4a8a577000 Original region address 0x2b4a8a577000 Region address 0x2b4a8a577138 Region primary address 0 Region maximum allocation 0 Region allocated Region allocations: 3006 allocations, 0 failures, 0 frees, 1 longest REGION_JOIN_OK Region flags =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by lockers: Locker Mode Count Status ----------------- Object --------------- 1 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 1 READ 1 HELD id2entry.bdb handle 0 2 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 3 dd= 0 locks held 1 write locks 0 pid/thread 32447/47463753631632 3 READ 1 HELD dn2id.bdb handle 0 4 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 5 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 6 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 7 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 7 READ 1 HELD objectClass.bdb handle 0 8 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 9 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 a dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 b dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 c dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 c READ 1 HELD cn.bdb handle 0 d dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 e dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 f dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 f READ 1 HELD uid.bdb handle 0 10 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 11 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 12 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 12 READ 1 HELD member.bdb handle 0 13 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 14 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 15 dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 15 READ 1 HELD mail.bdb handle 0 16 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 17 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 18 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 19 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1a dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 1a READ 1 HELD sn.bdb handle 0 1b dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1c dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1d dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1e dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 1f dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 80000003 dd= 0 locks held 0 write locks 0 pid/thread 32447/47463753631632 80000004 dd= 0 locks held 0 write locks 0 pid/thread 32447/1097341248 80000008 dd= 0 locks held 0 write locks 0 pid/thread 32447/1105733952 80000038 dd= 0 locks held 0 write locks 0 pid/thread 32447/1114126656 800000a9 dd= 0 locks held 1 write locks 0 pid/thread 32447/1097341248 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 800000aa dd= 0 locks held 2 write locks 0 pid/thread 32447/1097341248 800000aa WRITE 1 WAIT mail.bdb page 3 800000aa READ 1 HELD mail.bdb page 1 800000aa READ 1 HELD mail.bdb page 3 800000ab dd= 0 locks held 1 write locks 0 pid/thread 32447/1105733952 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 800000ac dd= 0 locks held 2 write locks 0 pid/thread 32447/1105733952 800000ac WRITE 1 WAIT mail.bdb page 3 800000ac READ 1 HELD mail.bdb page 1 800000ac READ 1 HELD mail.bdb page 3 800000b1 dd= 0 locks held 0 write locks 0 pid/thread 32447/1122519360 800000b2 dd= 0 locks held 0 write locks 0 pid/thread 32447/1130912064 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Locks grouped by object: Locker Mode Count Status ----------------- Object --------------- 800000a9 READ 1 HELD 0x2d228 len: 9 data: 0x370000000000000000 1 READ 1 HELD id2entry.bdb handle 0 3 READ 1 HELD dn2id.bdb handle 0 7 READ 1 HELD objectClass.bdb handle 0 f READ 1 HELD uid.bdb handle 0 1a READ 1 HELD sn.bdb handle 0 800000aa READ 1 HELD mail.bdb page 3 800000ac READ 1 HELD mail.bdb page 3 800000aa WRITE 1 WAIT mail.bdb page 3 800000ac WRITE 1 WAIT mail.bdb page 3 c READ 1 HELD cn.bdb handle 0 15 READ 1 HELD mail.bdb handle 0 800000aa READ 1 HELD mail.bdb page 1 800000ac READ 1 HELD mail.bdb page 1 12 READ 1 HELD member.bdb handle 0 800000ab READ 1 HELD 0x43d58 len: 9 data: 0x540x0500000000000000 We have also collected the backtrace of threads for both DB versions which I have uploaded to: https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.8.30_20130… https://dl.dropboxusercontent.com/u/92115703/dusan_gdb_threads_4.7.25_20130…

1 0

(ITS#7632) ldap_start_tls_s core dumps for 64 bit
by a16474＠gmail.com 25 Jun '13

25 Jun '13

Full_Name: Amit Sinha Version: openldap-2.4.35 OS: Linux 2.6.18-308.11.1.el5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.217.105) When i compile and run the below code on linux 64 bit, it core dumps in ldap_start_tls_s(). #include <ldap.h> #include <iostream> using namespace std; int main() { char* hostname = "myhost.mydomain.com" ; LDAP* l=ldap_init(hostname,389); int version = LDAP_VERSION3 ; if( LDAP_SUCCESS != ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, "7")) { cout << "error LDAP_OPT_DEBUG_LEVEL" << endl ; } if( LDAP_SUCCESS != ldap_set_option(l, LDAP_OPT_PROTOCOL_VERSION, &version )) { cout << "error LDAP_OPT_PROTOCOL_VERSION\n" ; } if( LDAP_SUCCESS != ldap_set_option(l, LDAP_OPT_REFERRALS, LDAP_OPT_OFF)) { cout << "error LDAP_OPT_REFERRALS\n" ; } if( LDAP_SUCCESS != ldap_set_option( NULL,LDAP_OPT_X_TLS_CTX,NULL )) { cout << "error LDAP_OPT_X_TLS_CTX\n" ; } /if( LDAP_SUCCESS != ldap_set_option( NULL,LDAP_OPT_X_TLS_CACERTDIR,"/myDirOfCert")) { cout << "error LDAP_OPT_X_TLS_CACERTDIR\n" ; } int rc ; if( LDAP_SUCCESS != ( rc = ldap_start_tls_s(l, NULL, NULL)) ) { cout << "error ldap_start_tls_s:" << ldap_err2string(rc) << endl ; } } BACKTRACE: (gdb) bt #0 0x00002b7d266bbbff in sk_value () from /root/openssl/openssl-1.0.1e/libcrypto.so.1.0.0 #1 0x00002b7d264a62fe in ssl3_output_cert_chain () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #2 0x00002b7d2649fffd in ssl3_send_client_certificate () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #3 0x00002b7d264a0531 in ssl3_connect () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #4 0x00002b7d264a9487 in ssl23_connect () from /root/openssl/openssl-1.0.1e/libssl.so.1.0.0 #5 0x00002b7d263676ec in tlso_session_connect (ld=<value optimized out>, sess=0x0) at tls_o.c:363 #6 0x00002b7d2636698d in ldap_int_tls_connect (ld=0x3d44e80, conn=0x3d675f0, srv=<value optimized out>) at tls2.c:362 #7 ldap_int_tls_start (ld=0x3d44e80, conn=0x3d675f0, srv=<value optimized out>) at tls2.c:860 #8 0x00002b7d26366d35 in ldap_start_tls_s (ld=0x3d44e80, serverctrls=0x0, clientctrls=<value optimized out>) at tls2.c:1040 #9 0x0000000000400dd2 in main () The open ssl version i am using is openssl-1.0.1e

1 0

Re: (ITS#7631) Overlay to rewrite value of attribute using regex
by bart＠icm.edu.pl 24 Jun '13

24 Jun '13

--=_c864110a076fc513331e0370bcb9adbe Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed I put patch here because the ftp server is full. DB --=_c864110a076fc513331e0370bcb9adbe Content-Transfer-Encoding: base64 Content-Type: text/plain; name=bart-130624.patch Content-Disposition: attachment; filename=bart-130624.patch RnJvbSBiOTM0MjdiZDVjYmNkMmJmOWMzYmM3M2IxYzE2NWYzNDY3MGRkOWY5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBiYXJ0IDxiYXJ0QG5iLWJhcnQuKG5vbmUpPgpEYXRlOiBNb24s IDI0IEp1biAyMDEzIDIzOjA2OjEwICswMjAwClN1YmplY3Q6IFtQQVRDSF0gT3ZlcmxheSB0byBy ZXdyaXRlIHZhbHVlIG9mIGF0dHJpYnV0ZSB1c2luZyByZWdleAoKLS0tCiBjb250cmliL3NsYXBk LW1vZHVsZXMvcmV3YXR0L01ha2VmaWxlIHwgICA0NiArKysrCiBjb250cmliL3NsYXBkLW1vZHVs ZXMvcmV3YXR0L3Jld2F0dC5jIHwgIDQ2NyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysKIDIgZmlsZXMgY2hhbmdlZCwgNTEzIGluc2VydGlvbnMoKyksIDAgZGVsZXRpb25zKC0pCiBj cmVhdGUgbW9kZSAxMDA2NDQgY29udHJpYi9zbGFwZC1tb2R1bGVzL3Jld2F0dC9NYWtlZmlsZQog Y3JlYXRlIG1vZGUgMTAwNjQ0IGNvbnRyaWIvc2xhcGQtbW9kdWxlcy9yZXdhdHQvcmV3YXR0LmMK CmRpZmYgLS1naXQgYS9jb250cmliL3NsYXBkLW1vZHVsZXMvcmV3YXR0L01ha2VmaWxlIGIvY29u dHJpYi9zbGFwZC1tb2R1bGVzL3Jld2F0dC9NYWtlZmlsZQpuZXcgZmlsZSBtb2RlIDEwMDY0NApp bmRleCAwMDAwMDAwLi5kNWQ5ZDEyCi0tLSAvZGV2L251bGwKKysrIGIvY29udHJpYi9zbGFwZC1t b2R1bGVzL3Jld2F0dC9NYWtlZmlsZQpAQCAtMCwwICsxLDQ2IEBACisjICRPcGVuTERBUCQKKwor TERBUF9TUkMgPSAuLi8uLi8uLgorTERBUF9CVUlMRCA9IC4uLy4uLy4uCitMREFQX0lOQyA9IC1J JChMREFQX0JVSUxEKS9pbmNsdWRlIC1JJChMREFQX1NSQykvaW5jbHVkZSAtSSQoTERBUF9TUkMp L3NlcnZlcnMvc2xhcGQKK0xEQVBfTElCID0gJChMREFQX0JVSUxEKS9saWJyYXJpZXMvbGlibGRh cF9yL2xpYmxkYXBfci5sYSBcCisJJChMREFQX0JVSUxEKS9saWJyYXJpZXMvbGlibGJlci9saWJs YmVyLmxhCisKK0xJQlRPT0wgPSAkKExEQVBfQlVJTEQpL2xpYnRvb2wKK0NDID0gZ2NjCitPUFQg PSAtZyAtTzIgLVdhbGwgLWdnZGIKK0RFRlMgPSAKK0lOQ1MgPSAkKExEQVBfSU5DKQorTElCUyA9 ICQoTERBUF9MSUIpCisKK1BST0dSQU1TID0gcmV3YXR0LmxhCitMVFZFUiA9IDA6MDowCisKK3By ZWZpeD0vdXNyL2xvY2FsCitleGVjX3ByZWZpeD0kKHByZWZpeCkKK2xkYXBfc3ViZGlyPS9vcGVu bGRhcAorCitsaWJkaXI9JChleGVjX3ByZWZpeCkvbGliCitsaWJleGVjZGlyPSQoZXhlY19wcmVm aXgpL2xpYmV4ZWMKK21vZHVsZWRpciA9ICQobGliZXhlY2RpcikkKGxkYXBfc3ViZGlyKQorCisu U1VGRklYRVM6IC5jIC5vIC5sbworCisuYy5sbzoKKwkkKExJQlRPT0wpIC0tbW9kZT1jb21waWxl ICQoQ0MpICQoT1BUKSAkKERFRlMpICQoSU5DUykgLWMgJDwKKworYWxsOiAkKFBST0dSQU1TKQor CityZXdhdHQubGE6IHJld2F0dC5sbworCSQoTElCVE9PTCkgLS1tb2RlPWxpbmsgJChDQykgJChP UFQpIC12ZXJzaW9uLWluZm8gJChMVFZFUikgXAorCS1ycGF0aCAkKG1vZHVsZWRpcikgLW1vZHVs ZSAtbyAkQCAkPyAkKExJQlMpCisKK2NsZWFuOgorCXJtIC1yZiAqLm8gKi5sbyAqLmxhIC5saWJz CisKK2luc3RhbGw6ICQoUFJPR1JBTVMpCisJbWtkaXIgLXAgJChERVNURElSKSQobW9kdWxlZGly KQorCWZvciBwIGluICQoUFJPR1JBTVMpIDsgZG8gXAorCQkkKExJQlRPT0wpIC0tbW9kZT1pbnN0 YWxsIGNwICQkcCAkKERFU1RESVIpJChtb2R1bGVkaXIpIDsgXAorCWRvbmUKKwpkaWZmIC0tZ2l0 IGEvY29udHJpYi9zbGFwZC1tb2R1bGVzL3Jld2F0dC9yZXdhdHQuYyBiL2NvbnRyaWIvc2xhcGQt bW9kdWxlcy9yZXdhdHQvcmV3YXR0LmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAw MC4uNjgzYmVjYwotLS0gL2Rldi9udWxsCisrKyBiL2NvbnRyaWIvc2xhcGQtbW9kdWxlcy9yZXdh dHQvcmV3YXR0LmMKQEAgLTAsMCArMSw0NjcgQEAKKy8qIHJld2F0dC5jIC0gT3ZlcmxheSB0byBy ZXdyaXRlIHNvbWUgYXR0cmlidXRlICAqLworLyogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBz b3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24s IGFyZSBwZXJtaXR0ZWQgb25seSBhcyBhdXRob3JpemVkIGJ5IHRoZSBPcGVuTERBUAorICogUHVi bGljIExpY2Vuc2UuCisgKgorICogQSBjb3B5IG9mIHRoaXMgbGljZW5zZSBpcyBhdmFpbGFibGUg aW4gdGhlIGZpbGUgTElDRU5TRSBpbiB0aGUKKyAqIHRvcC1sZXZlbCBkaXJlY3Rvcnkgb2YgdGhl IGRpc3RyaWJ1dGlvbiBvciwgYWx0ZXJuYXRpdmVseSwgYXQKKyAqIDxodHRwOi8vd3d3Lk9wZW5M REFQLm9yZy9saWNlbnNlLmh0bWw+LgorICovCisvKiBBQ0tOT1dMRURHRU1FTlRTOgorICogVGhp cyB3b3JrIHdhcyBvcmlnaW5hbGx5IGRldmVsb3BlZCBieSB0aGUgRG9taW5payBCYXJ0a2lld2lj eiBiYXJ0QGljbS5lZHUucGwgZm9yCisgKiBpbmNsdXNpb24gaW4gT3BlbkxEQVAgU29mdHdhcmUu CisgKi8KKworI2luY2x1ZGUgInBvcnRhYmxlLmgiCisKKyNpbmNsdWRlIDxzdGRpby5oPgorI2lu Y2x1ZGUgPHJlZ2V4Lmg+CisKKyNpbmNsdWRlICJhYy9zdHJpbmcuaCIKKyNpbmNsdWRlICJhYy9z b2NrZXQuaCIKKworI2luY2x1ZGUgImx1dGlsLmgiCisjaW5jbHVkZSAic2xhcC5oIgorI2luY2x1 ZGUgImNvbmZpZy5oIgorCisjZGVmaW5lIE1BWF9NQVRDSEVTIDEKKworZW51bSB7CisJUkVXQVRU X0FUVFJJQlVURT0xLAorCVJFV0FUVF9SRUdFWCwKKwlSRVdBVFRfU1VCLAorCVJFV0FUVF9BVFRS SUJVVEVfVCwKKwlSRVdBVFRfUkVHRVhfVAorfTsKKworCit0eXBlZGVmIHN0cnVjdCByZXdhdHRf aW5mb190IHsKKwlBdHRyaWJ1dGVEZXNjcmlwdGlvbgkqcmFfYXR0cmlidXRlOworCXJlZ2V4X3QJ CQkqcmFfcmVnZXg7CisJY2hhcgkJKnJhX3N1YjsKKwlBdHRyaWJ1dGVEZXNjcmlwdGlvbgkqcmFf YXR0cmlidXRlX3Q7CisJcmVnZXhfdAkJCSpyYV9yZWdleF90OworCXN0cnVjdCByZXdhdHRfaW5m b190CSpyYV9uZXh0OworfSByZXdhdHRfaW5mb190OworCitzdGF0aWMgaW50CityZXdhdHRfY2Zn ZW4oIENvbmZpZ0FyZ3MgKmMgKQoreworCXNsYXBfb3Zlcmluc3QJKm9uID0gKHNsYXBfb3Zlcmlu c3QgKiljLT5iaTsKKwlyZXdhdHRfaW5mb190CSpjaSA9IChyZXdhdHRfaW5mb190ICopb24tPm9u X2JpLmJpX3ByaXZhdGUgOworCisgICAgICAgIGlmKCBjaSA9PSBOVUxMICkgeworICAgICAgICAg ICAgICAgIGNpID0gKHJld2F0dF9pbmZvX3QqKWNoX2NhbGxvYyggMSwgc2l6ZW9mKHJld2F0dF9p bmZvX3QpICk7CisJCWNpIC0+IHJhX3JlZ2V4ID0gTlVMTDsKKwkJY2kgLT4gcmFfcmVnZXggPSBO VUxMOworCQljaSAtPiByYV9zdWIgPSBOVUxMOworCQljaSAtPiByYV9hdHRyaWJ1dGUgPSBOVUxM OworCQljaSAtPiByYV9hdHRyaWJ1dGVfdCA9IE5VTEw7CisJCWNpIC0+IHJhX25leHQgPSBOVUxM OworCQlvbi0+b25fYmkuYmlfcHJpdmF0ZT0gKHZvaWQgKikgY2k7CisJCURlYnVnKCBMREFQX0RF QlVHX1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIG9uLT5vbl9iaS5iaV9wcml2YXRlPSAlcCBcbiIs IG9uLT5vbl9iaS5iaV9wcml2YXRlLCAwLCAwKTsKKyAgICAgICAgfSBlbHNlIHsKKwkJZm9yICg7 Y2k7Y2k9Y2ktPnJhX25leHQpIHsKKyAgICAgICAgCQlpZiggY2ktPnJhX25leHQgPT0gTlVMTCAp IHsKKwkJCQlpZihjaS0+cmFfYXR0cmlidXRlICE9IE5VTEwgJiYgYy0+dHlwZSA9PSBSRVdBVFRf QVRUUklCVVRFICYmICBjLT5vcCAhPSBTTEFQX0NPTkZJR19FTUlUICYmIGMtPm9wICE9ICBMREFQ X01PRF9ERUxFVEUpeworICAgICAgICAgICAgICAgIAkJCWNpLT5yYV9uZXh0ID0gKHJld2F0dF9p bmZvX3QqKWNoX2NhbGxvYyggMSwgc2l6ZW9mKHJld2F0dF9pbmZvX3QpICk7CisJCQkJCWNpLT5y YV9uZXh0IC0+IHJhX3JlZ2V4ID0gTlVMTDsKKwkJCQkJY2ktPnJhX25leHQgLT4gcmFfcmVnZXhf dCA9IE5VTEw7CisJCQkJCWNpLT5yYV9uZXh0IC0+IHJhX3N1YiA9IE5VTEw7CisJCQkJCWNpLT5y YV9uZXh0IC0+IHJhX2F0dHJpYnV0ZSA9IE5VTEw7CisJCQkJCWNpLT5yYV9uZXh0IC0+IHJhX2F0 dHJpYnV0ZV90ID0gTlVMTDsKKwkJCQkJY2ktPnJhX25leHQgLT4gcmFfbmV4dCA9IE5VTEw7CisJ CQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIG9uLT5vbl9iaS5i aV9wcml2YXRlPSAlcCBcbiIsIG9uLT5vbl9iaS5iaV9wcml2YXRlLCAwLCAwKTsKKwkJCQl9IGVs c2UgeworCQkJCQlicmVhazsKKwkJCQl9CisgICAgICAgIAkJfQorCQkJCisJCX0KKworCX0KKwor CWNvbnN0IGNoYXIJCSp0ZXh0OworCWludCByYyA9IDE7CisJaW50IHIgPSAxOworCWludCBpID0g MDsKKwlpbnQgbGVuID0gMDsKKwlmb3IoaT0wO2k8Yy0+YXJnYztpKyspeworCQlEZWJ1ZyggTERB UF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbjogICBjLT5hcmd2WyVkXTogJXNcbiIsIGksIGMt PmFyZ3ZbaV0sIDApOworCX0KKwlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdl bjogICBjLT5vcDogJWRcbiIsICBjLT5vcCwgMCwwKTsKKwlpZiAoIGMtPm9wID09IFNMQVBfQ09O RklHX0VNSVQgKSB7CisJCWNpID0gb24tPm9uX2JpLmJpX3ByaXZhdGUgOworCQlzdHJ1Y3QgYmVy dmFsCWJ2OworCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbiBTTEFQX0NP TkZJR19FTUlUIDogICBjLT50eXBlOiAlZFxuIiwgIGMtPnR5cGUsIDAsMCk7CisJCXN3aXRjaChj LT50eXBlKSB7CisJCWNhc2UgUkVXQVRUX0FUVFJJQlVURToKKwkJCWxlbiA9IHNucHJpbnRmKCBj LT5jcl9tc2csIHNpemVvZiggYy0+Y3JfbXNnICksCisJCQkJICIlcyIsIAorCQkJCWNpLT5yYV9h dHRyaWJ1dGUtPmFkX2NuYW1lLmJ2X3ZhbCApOworCisJCQlidi5idl92YWwgPSBjLT5jcl9tc2c7 CisJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbiBSRVdBVFRfQVRUUklC VVRFOiAgIGMtPmNyX21zZzogJXNcbiIsICBjLT5jcl9tc2csIDAsMCk7CisJCQlidi5idl9sZW4g PSBsZW47CisJCQl2YWx1ZV9hZGRfb25lICggJmMtPnJ2YWx1ZV92YWxzLCAmYnYgKTsKKwkJCXJj ID0gMDsKKwkJCWJyZWFrOworCQljYXNlIFJFV0FUVF9SRUdFWDoKKworCQkJLy9sZW4gPSBzbnBy aW50ZiggYy0+Y3JfbXNnLCBzaXplb2YoIGMtPmNyX21zZyApLCAiJXMiLCBjaS0+cmFfcmVnZXhw ICk7CisJCQkvL2J2LmJ2X3ZhbCA9IGMtPmNyX21zZzsKKwkJCS8vRGVidWcoIExEQVBfREVCVUdf VFJBQ0UsICJyZXdhdHRfY2ZnZW4gUkVXQVRUX1JFR0VYUDogICBjLT5jcl9tc2c6ICVzXG4iLCAg Yy0+Y3JfbXNnLCAwLDApOworCQkJLy9idi5idl9sZW4gPSBsZW47CisJCQkvL3ZhbHVlX2FkZF9v bmUgKCAmYy0+cnZhbHVlX3ZhbHMsICZidiApOworCQkJcmMgPSAwOworCQkJYnJlYWs7CisJCWNh c2UgUkVXQVRUX1NVQjoKKwkJCWlmICggY2ktPnJhX3N1YiApeworCQkJCWxlbiA9IHNucHJpbnRm KCBjLT5jcl9tc2csIHNpemVvZiggYy0+Y3JfbXNnICksCisJCQkJCSIlcyIsCisJCQkJCWNpLT5y YV9zdWIgKTsKKworCQkJCWJ2LmJ2X3ZhbCA9IGMtPmNyX21zZzsKKwkJCQlEZWJ1ZyggTERBUF9E RUJVR19UUkFDRSwgInJld2F0dF9jZmdlbiBSRVdBVFRfU1VCOiAgIGMtPmNyX21zZzogJXNcbiIs ICBjLT5jcl9tc2csIDAsMCk7CisJCQkJYnYuYnZfbGVuID0gbGVuOworCQkJCXZhbHVlX2FkZF9v bmUgKCAmYy0+cnZhbHVlX3ZhbHMsICZidiApOworCQkJfQorCQkJcmMgPSAwOworCQkJYnJlYWs7 CisJCWNhc2UgUkVXQVRUX0FUVFJJQlVURV9UOgorCQkJaWYoY2ktPnJhX2F0dHJpYnV0ZV90KXsK KwkJCQlsZW4gPSBzbnByaW50ZiggYy0+Y3JfbXNnLCBzaXplb2YoIGMtPmNyX21zZyApLAorCQkJ CQkgIiVzIiwgCisJCQkJCWNpLT5yYV9hdHRyaWJ1dGVfdC0+YWRfY25hbWUuYnZfdmFsICk7CisJ CQkJYnYuYnZfdmFsID0gYy0+Y3JfbXNnOworCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAi cmV3YXR0X2NmZ2VuIFJFV0FUVF9BVFRSSUJVVEU6ICAgYy0+Y3JfbXNnOiAlc1xuIiwgIGMtPmNy X21zZywgMCwwKTsKKwkJCQlidi5idl9sZW4gPSBsZW47CisJCQkJdmFsdWVfYWRkX29uZSAoICZj LT5ydmFsdWVfdmFscywgJmJ2ICk7CisJCQl9CisJCQlyYyA9IDA7CisJCQlicmVhazsKKwkJY2Fz ZSBSRVdBVFRfUkVHRVhfVDoKKwkJCXJjID0gMDsKKwkJCWJyZWFrOworCisJCWRlZmF1bHQ6CisJ CQlyYyA9IDE7CisJCQlicmVhazsKKwkJfQorCQlyZXR1cm4gcmM7CisJfSBlbHNlIGlmICggYy0+ b3AgPT0gTERBUF9NT0RfREVMRVRFICkgeworCSAgICAgICAgLyogRklYTUUgKi8KKwkgICAgICAg IHJldHVybiAxOworCX0KKwlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9jZmdlbjog ICBjLT50eXBlOiAlZFxuIiwgIGMtPnR5cGUsIDAsMCk7CisJc3dpdGNoKCBjLT50eXBlICkgewor CWNhc2UgUkVXQVRUX0FUVFJJQlVURToKKwkJaWYgKCBjLT5hcmdjID09IDIgKXsKKwkJCXIgPSBz bGFwX3N0cjJhZCggYy0+YXJndlsxXSwgJihjaS0+cmFfYXR0cmlidXRlKSwgJnRleHQgKTsKKwkJ CWlmICggciAhPSBMREFQX1NVQ0NFU1MgKSB7CisJCQkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0Us ICJyZXdhdHRfY2ZnZW46ICBzbGFwX3N0cjJhZDogcmV0dXJuIGNvZGUgPSAlZFxuIiwgciwgMCww KTsKKwkJCQlyYyA9IDE7CisJCQl9IGVsc2UgeworCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNF LCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9hdHRyaWJ1dGUtPmFkX2NuYW1lLmJ2X3ZhbCA9ICVz XG4iLCAgY2ktPnJhX2F0dHJpYnV0ZS0+YWRfY25hbWUuYnZfdmFsICwgMCwwKTsKKwkJCQlyYyA9 IDA7CisJCQl9CisJCX0KKwkJYnJlYWs7CisJY2FzZSBSRVdBVFRfUkVHRVg6CisJCWlmICggYy0+ YXJnYyA9PSAyICl7CisJCQljaS0+cmFfcmVnZXg9KHJlZ2V4X3QgKilTTEFQX01BTExPQyhzaXpl b2YocmVnZXhfdCkpOworCQkJciA9IHJlZ2NvbXAoY2ktPnJhX3JlZ2V4LCBjLT5hcmd2WzFdLCBS RUdfRVhURU5ERUQpOworCQkJaWYoIHIgKXsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwg InJld2F0dF9jZmdlbjogQ291bGQgbm90IGNvbXBpbGUgcmVnZXggciA9ICVkXG4iLCByICwgMCww KTsKKwkJCQlyZWdmcmVlKGNpLT5yYV9yZWdleCk7CisJCQkJY2ktPnJhX3JlZ2V4PU5VTEw7CisJ CQkJcmMgPSAxOworCQkJfSBlbHNlIHsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJl d2F0dF9jZmdlbjogICBjaS0+cmFfcmVnZXggbWFrZSBmcm9tICM+ICVzIDwjJ1xuIiwgIGMtPmFy Z3ZbMV0gLCAwLDApOworCQkJCXJjID0gMDsKKwkJCX0KKwkJfQorCQlicmVhazsKKwljYXNlIFJF V0FUVF9TVUI6CisJCWlmICggYy0+YXJnYyA9PSAyICl7CisJCQljaS0+cmFfc3ViPVNMQVBfTUFM TE9DKChzdHJsZW4oYy0+YXJndlsxXSkrMSkqIHNpemVvZihjaGFyKSApOworCQkJRGVidWcoIExE QVBfREVCVUdfVFJBQ0UsICJyZXdhdHRfY2ZnZW46ICAgY2ktPnJhX3N1Yj1tYWxsb2MoJWx1KVxu IiwgICgoc3RybGVuKGMtPmFyZ3ZbMV0pKzEpKiBzaXplb2YoY2hhcikgKSwgMCwwKTsKKwkJCXN0 cm5jcHkoY2ktPnJhX3N1YixjLT5hcmd2WzFdLHN0cmxlbihjLT5hcmd2WzFdKSk7CisJCQljaS0+ cmFfc3ViW3N0cmxlbihjLT5hcmd2WzFdKV09J1wwJzsKKwkJCURlYnVnKCBMREFQX0RFQlVHX1RS QUNFLCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9zdWI9ICVzXG4iLCAgY2ktPnJhX3N1YiwgMCww KTsKKwkJCXJjID0gMDsKKwkJfSBlbHNlIHsKKwkJCWNpLT5yYV9zdWI9bWFsbG9jKHNpemVvZihj aGFyKSk7CisJCQljaS0+cmFfc3ViWzBdPSdcMCc7CisJCQlyYyA9IDA7CisJCX0KKwkJYnJlYWs7 CisJY2FzZSBSRVdBVFRfQVRUUklCVVRFX1Q6CisJCWlmICggYy0+YXJnYyA9PSAyICl7CisJCQly ID0gc2xhcF9zdHIyYWQoIGMtPmFyZ3ZbMV0sICYoY2ktPnJhX2F0dHJpYnV0ZV90KSwgJnRleHQg KTsKKwkJCWlmICggciAhPSBMREFQX1NVQ0NFU1MgKSB7CisJCQkJRGVidWcoIExEQVBfREVCVUdf VFJBQ0UsICJyZXdhdHRfY2ZnZW46ICBzbGFwX3N0cjJhZDogcmV0dXJuIGNvZGUgPSAlZFxuIiwg ciwgMCwwKTsKKwkJCQlyYyA9IDE7CisJCQl9IGVsc2UgeworCQkJCURlYnVnKCBMREFQX0RFQlVH X1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9hdHRyaWJ1dGVfdC0+YWRfY25hbWUuYnZf dmFsID0gJXNcbiIsICBjaS0+cmFfYXR0cmlidXRlX3QtPmFkX2NuYW1lLmJ2X3ZhbCAsIDAsMCk7 CisJCQkJcmMgPSAwOworCQkJfQorCQl9CisJCWJyZWFrOworCWNhc2UgUkVXQVRUX1JFR0VYX1Q6 CisJCWlmICggYy0+YXJnYyA9PSAyICl7CisJCQljaS0+cmFfcmVnZXhfdD0ocmVnZXhfdCAqKVNM QVBfTUFMTE9DKHNpemVvZihyZWdleF90KSk7CisJCQlyID0gcmVnY29tcChjaS0+cmFfcmVnZXhf dCwgYy0+YXJndlsxXSwgUkVHX0VYVEVOREVEKTsKKwkJCWlmKCByICl7CisJCQkJRGVidWcoIExE QVBfREVCVUdfVFJBQ0UsICJyZXdhdHRfY2ZnZW46IENvdWxkIG5vdCBjb21waWxlIHJlZ2V4IHIg PSAlZFxuIiwgciAsIDAsMCk7CisJCQkJcmVnZnJlZShjaS0+cmFfcmVnZXhfdCk7CisJCQkJY2kt PnJhX3JlZ2V4X3Q9TlVMTDsKKwkJCQlyYyA9IDE7CisJCQl9IGVsc2UgeworCQkJCURlYnVnKCBM REFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X2NmZ2VuOiAgIGNpLT5yYV9yZWdleF90IG1ha2UgZnJv bSAjPiAlcyA8IydcbiIsICBjLT5hcmd2WzFdICwgMCwwKTsKKwkJCQlyYyA9IDA7CisJCQl9CisJ CX0KKwkJYnJlYWs7CisKKworCWRlZmF1bHQ6CQkKKwkJcmV0dXJuIDE7CisJCWJyZWFrOworCX0K KwlyZXR1cm4gcmM7Cit9CitzdGF0aWMgaW50CityZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiKCBP cGVyYXRpb24gKm9wLCBTbGFwUmVwbHkgKnJzICkKK3sKKwlzbGFwX2NhbGxiYWNrICAgKnNjOwor CXJld2F0dF9pbmZvX3QJKnJhaTsKKwlFbnRyeQkJKmUgPSBOVUxMOworCUF0dHJpYnV0ZSAqYTsK KwljaGFyIG1zZ2J1ZlsxMDBdOworCWludCByZXRpOworCWludCBpOworCisJYXNzZXJ0KCBvcCAm JiBvcC0+b19jYWxsYmFjayAmJiBycyApOworCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3 YXR0X3NlYXJjaF9yZXNwb25zZV9jYiBcbiIsIDAsIDAsMCk7CisJaWYgKCBycy0+c3JfdHlwZSAh PSBSRVBfU0VBUkNIIHx8ICFycy0+c3JfZW50cnkgKSB7CisJCXNsYXBfZnJlZXNlbGZfY2IoIG9w LCBycyApOworCQlyZXR1cm4gKCBTTEFQX0NCX0NPTlRJTlVFICk7CisJfQorCXNjID0gb3AtPm9f Y2FsbGJhY2s7CisJcmFpID0gKHJld2F0dF9pbmZvX3QgKilzYy0+c2NfcHJpdmF0ZTsKKworCWZv ciAocmFpID0gKHJld2F0dF9pbmZvX3QgKilzYy0+c2NfcHJpdmF0ZTtyYWk7cmFpPXJhaS0+cmFf bmV4dCl7CisJCS8vRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsICJyZXdhdHRfc2VhcmNoX3Jlc3Bv bnNlX2NiOiByYWkgPSAlcCBcbiIsIHJhaSwgMCwgMCk7CisJCWUgPSBycy0+c3JfZW50cnk7CisJ CWZvciAoIGEgPSBlLT5lX2F0dHJzOyBhOyBhID0gYS0+YV9uZXh0ICkgeworCQkJaWYgKCBhLT5h X2Rlc2MgPT0gcmFpLT5yYV9hdHRyaWJ1dGUgKSB7CisJCQkJRGVidWcoIExEQVBfREVCVUdfVFJB Q0UsICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiByZXdhdHQgZmluZDogJXNcbiIsIGEtPmFf ZGVzYy0+YWRfY25hbWUuYnZfdmFsLCAwLDApOworCQkJCWJyZWFrOworCQkJCX0KKwkJfQorCisJ CWlmICggYSA9PSBOVUxMICkgeworCQkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsICJyZXdhdHRf c2VhcmNoX3Jlc3BvbnNlX2NiOiByZXdhdHQgbm90IGZpbmQ6ICVzXG4iLCByYWktPnJhX2F0dHJp YnV0ZS0+YWRfY25hbWUuYnZfdmFsLCAwLDApOworCQkJY29udGludWU7CisJCX0KKworCQlEZWJ1 ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IGEtPmFfZGVz Yy0+YWRfY25hbWUuYnZfdmFsOiAlc1xuIiwgYS0+YV9kZXNjLT5hZF9jbmFtZS5idl92YWwsIDAs MCk7CisKKwkJaWYgKCByYWktPnJhX2F0dHJpYnV0ZV90ICE9IE5VTEwgKXsKKwkJCWZvciAoIGEg PSBlLT5lX2F0dHJzOyBhOyBhID0gYS0+YV9uZXh0ICkgeworCQkJCWlmICggYS0+YV9kZXNjID09 IHJhaS0+cmFfYXR0cmlidXRlX3QgKSB7CisJCQkJCWJyZWFrOworCQkJCQl9CisJCQl9CisJCisJ CQlpZiAoIGEgPT0gTlVMTCApIHsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0 dF9zZWFyY2hfcmVzcG9uc2VfY2I6IHJld2F0dCBub3QgZmluZCByYV9hdHRyaWJ1dGVfdCA6ICVz XG4iLCByYWktPnJhX2F0dHJpYnV0ZV90LT5hZF9jbmFtZS5idl92YWwsIDAsMCk7CisJCQkJY29u dGludWU7CisJCQl9CisJCX0KKwkJaWYgKCByYWktPnJhX2F0dHJpYnV0ZV90ICE9IE5VTEwgJiYg cmFpLT5yYV9yZWdleF90ICE9IE5VTEwpeworCQkJZm9yICggYSA9IGUtPmVfYXR0cnM7IGE7IGEg PSBhLT5hX25leHQgKSB7CisJCQkJaWYgKCBhLT5hX2Rlc2MgPT0gcmFpLT5yYV9hdHRyaWJ1dGVf dCApIHsKKwkJCQkJCWZvcihpPTA7aSA8IGEtPmFfbnVtdmFscyA7aSsrKXsKKwkJCQkJCQkgcmV0 aSA9IHJlZ2V4ZWMocmFpLT5yYV9yZWdleF90LCBhLT5hX3ZhbHNbaV0uYnZfdmFsICwgMCAsIE5V TEwgLCBSRUdfTk9UQk9MIHwgUkVHX05PVEVPTCk7CisJCQkJCQkJIGlmIChyZXRpID09IDApIGJy ZWFrOworCQkJCQkJfQorCQkJCQkJaWYgKHJldGkgPT0gMCApIGJyZWFrOworCQkJCQl9CisJCQl9 CisJCisJCQlpZiAoIGEgPT0gTlVMTCApIHsKKwkJCQlEZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwg InJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IHJhX3JlZ2V4X3QgUkVHX05PTUFUQ0ggaW4gJXMg XG4iLCAgcmFpLT5yYV9hdHRyaWJ1dGVfdC0+YWRfY25hbWUuYnZfdmFsICwgMCwwKTsKKwkJCQlj b250aW51ZTsKKwkJCX0KKworCQl9CisKKwkJLy9OZXcgZnVuY3Rpb24gZm9yIHNsYXBkID4gMi40 LjI0CisJCXJzX2VudHJ5Mm1vZGlmaWFibGUoIG9wLCBycywgKHNsYXBfb3Zlcmluc3QgKikgb3At Pm9fYmQtPmJkX2luZm8gKTsKKwkJLy9yc19lbnN1cmVfZW50cnlfbW9kaWZpYWJsZSggb3AsIHJz LCAoc2xhcF9vdmVyaW5zdCAqKSBvcC0+b19iZC0+YmRfaW5mbyApOworCQllID0gcnMtPnNyX2Vu dHJ5OworCisJCWZvciAoIGEgPSBlLT5lX2F0dHJzOyBhOyBhID0gYS0+YV9uZXh0ICkgeworCQkJ aWYgKCBhLT5hX2Rlc2MgIT0gIHJhaS0+cmFfYXR0cmlidXRlICkKKwkJCQljb250aW51ZTsKKwkJ CWZvcihpPTA7aSA8IGEtPmFfbnVtdmFscyA7aSsrKXsKKworCisJCQkJRGVidWcoIExEQVBfREVC VUdfVFJBQ0UsICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiBvbGQgIHZhbHVlICAlc1xuIiwg YS0+YV92YWxzW2ldLmJ2X3ZhbCwgMCwwICk7CisJCQkJRGVidWcoIExEQVBfREVCVUdfVFJBQ0Us ICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiBvbGQgbnZhbHVlICAlc1xuIiwgYS0+YV9udmFs c1tpXS5idl92YWwsIDAsMCApOworCisJCQkJaW50IGo7CisJCQkJY2hhciAqIHZhbF90bXA9TlVM TDsKKwkJCQlyZWdtYXRjaF90IG1hdGNoZXNbTUFYX01BVENIRVNdOworCQkJCQorCQkJCS8qIEV4 ZWN1dGUgcmVndWxhciBleHByZXNzaW9uICovCisJCQkJcmV0aSA9IHJlZ2V4ZWMocmFpLT5yYV9y ZWdleCwgYS0+YV92YWxzW2ldLmJ2X3ZhbCAsIE1BWF9NQVRDSEVTICwgbWF0Y2hlcyAsIFJFR19O T1RCT0wgfCBSRUdfTk9URU9MKTsKKworCQkJCWlmKCAhcmV0aSApeworCQkJCQlmb3IgKGogPSAw OyBqIDwgIE1BWF9NQVRDSEVTOyBqKyspIHsKKwkJCQkJCWlmIChtYXRjaGVzW2pdLnJtX3NvID09 IC0xKSB7CisJCQkJCQkgICAgYnJlYWs7CisJCQkJCQl9CisJCQkJCQlpZiAoaiA9PSAwICkgewor CQkJCQkJCXZhbF90bXAgPSByZWFsbG9jKHZhbF90bXAgLCAoc3RybGVuKHJhaS0+cmFfc3ViKSAt IG1hdGNoZXNbal0ucm1fZW8gKyBtYXRjaGVzW2pdLnJtX3NvICsxICsgc3RybGVuKGEtPmFfdmFs c1tpXS5idl92YWwpICkgKiBzaXplb2YoY2hhcikpOworCQkJCQkJCWlmKG1hdGNoZXNbal0ucm1f c28gPiAwKQorCQkJCQkJCQlzdHJuY3B5KCB2YWxfdG1wLCAgYS0+YV92YWxzW2ldLmJ2X3ZhbCwg bWF0Y2hlc1tqXS5ybV9zbyk7CisJCQkJCQkJc3RyY3B5KCB2YWxfdG1wICsgbWF0Y2hlc1tqXS5y bV9zbywgIHJhaS0+cmFfc3ViKTsKKwkJCQkJCQlzdHJjcHkoIHZhbF90bXAgKyBzdHJsZW4odmFs X3RtcCkgLCBhLT5hX3ZhbHNbaV0uYnZfdmFsICsgbWF0Y2hlc1tqXS5ybV9lbyApOworCQkJCQkJ fQorCQkJCQl9CisJCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X3NlYXJjaF9y ZXNwb25zZV9jYjogdmFsX3RtcCB2YWx1ZTogJXNcbiIsIHZhbF90bXAsIDAsIDAgKTsKKwkJCQkJ YS0+YV92YWxzW2ldLmJ2X3ZhbCA9IHJlYWxsb2MoIGEtPmFfdmFsc1tpXS5idl92YWwgLCAoIHN0 cmxlbih2YWxfdG1wKSArIDEgKSAqIHNpemVvZihjaGFyKSAgKTsKKwkJCQkJYS0+YV9udmFsc1tp XS5idl92YWwgPSByZWFsbG9jKCBhLT5hX252YWxzW2ldLmJ2X3ZhbCAsICggc3RybGVuKHZhbF90 bXApICsgMSApICAqIHNpemVvZihjaGFyKSAgKTsKKwkJCQkJRGVidWcoIExEQVBfREVCVUdfVFJB Q0UsICJyZXdhdHRfc2VhcmNoX3Jlc3BvbnNlX2NiOiBhZnRlciBTTEFQX1JFQUxMT0MgYS0+YV9b bl12YWxzWyVkXS0+YnZfdmFsIHRvICAlbHVcbiIsIGkgLChzdHJsZW4odmFsX3RtcCkrMSkqc2l6 ZW9mKGNoYXIpLCAwICk7CisJCQkJCXN0cmNweSggYS0+YV92YWxzW2ldLmJ2X3ZhbCAsdmFsX3Rt cCk7CisJCQkJCXN0cmNweSggYS0+YV9udmFsc1tpXS5idl92YWwgLHZhbF90bXApOworCQkJCQlE ZWJ1ZyggTERBUF9ERUJVR19UUkFDRSwgInJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IG5ldyBh LT5hX1tuXXZhbHNbJWRdLmJ2X3ZhbD0gJXNcbiIsaSwgYS0+YV9udmFsc1tpXS5idl92YWwsIDAg KTsKKwkJCQkJYS0+YV92YWxzW2ldLmJ2X2xlbj0gc3RybGVuKHZhbF90bXApIDsKKwkJCQkJYS0+ YV9udmFsc1tpXS5idl9sZW49IHN0cmxlbih2YWxfdG1wKSA7CisJCQkJCURlYnVnKCBMREFQX0RF QlVHX1RSQUNFLCAicmV3YXR0X3NlYXJjaF9yZXNwb25zZV9jYjogbmV3IGEtPmFfW25ddmFsc1sl ZF0uYnZfbGVuPSAlenVcbiIsaSwgc3RybGVuKHZhbF90bXApLCAwICk7CisJCQkJCWlmICh2YWxf dG1wKSBmcmVlKHZhbF90bXApOworCQkJCX0KKwkJCQllbHNlIGlmKCByZXRpID09IFJFR19OT01B VENIICl7CisJCQkJCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X3NlYXJjaF9yZXNw b25zZV9jYjogUkVHX05PTUFUQ0ggaW4gOiAlc1xuIiwgIGEtPmFfdmFsc1tpXS5idl92YWwgICwg MCwwKTsKKwkJCQl9CisJCQkJZWxzZXsKKwkJCQkgICAgICAgIHJlZ2Vycm9yKHJldGksIHJhaS0+ cmFfcmVnZXgsIG1zZ2J1Ziwgc2l6ZW9mKG1zZ2J1ZikpOworCQkJCQlEZWJ1ZyggTERBUF9ERUJV R19UUkFDRSwgInJld2F0dF9zZWFyY2hfcmVzcG9uc2VfY2I6IFJlZ2V4IG1hdGNoIGZhaWxlZDog JXNcbiIsICBtc2didWYgLCAwLDApOworCQkJCQlicmVhazsKKwkJCQl9CisJCQl9CisKKyAgICAg ICAgCX0KKwl9CisJcmV0dXJuICggU0xBUF9DQl9DT05USU5VRSApOworfQorCitzdGF0aWMgaW50 CityZXdhdHRfc2VhcmNoX2NsZWFudXBfY2IoIE9wZXJhdGlvbiAqb3AsIFNsYXBSZXBseSAqcnMg KQoreworCWlmICggcnMtPnNyX3R5cGUgPT0gUkVQX1JFU1VMVCB8fCBycy0+c3JfZXJyICE9IExE QVBfU1VDQ0VTUyApIHsKKwkJc2xhcF9mcmVlc2VsZl9jYiggb3AsIHJzICk7CisJfQorCisJcmV0 dXJuIFNMQVBfQ0JfQ09OVElOVUU7Cit9CisKK3N0YXRpYyBpbnQKK3Jld2F0dF9zZWFyY2goIE9w ZXJhdGlvbiAqb3AsIFNsYXBSZXBseSAqcnMgKQoreworICAgICAgICBzbGFwX292ZXJpbnN0ICAg Km9uID0gKHNsYXBfb3Zlcmluc3QgKilvcC0+b19iZC0+YmRfaW5mbzsKKyAgICAgICAgcmV3YXR0 X2luZm9fdCAgICAqY2kgPSAocmV3YXR0X2luZm9fdCAqKW9uLT5vbl9iaS5iaV9wcml2YXRlOwor CXNsYXBfY2FsbGJhY2sJKnNjOworCisJRGVidWcoIExEQVBfREVCVUdfVFJBQ0UsICJyZXdhdHRf c2VhcmNoIFxuIiwgMCwgMCwgMCApOworCXNjID0gb3AtPm9fdG1wY2FsbG9jKCAxLCBzaXplb2Yo ICpzYyApLCBvcC0+b190bXBtZW1jdHggKTsKKwlzYy0+c2NfcmVzcG9uc2UgPSByZXdhdHRfc2Vh cmNoX3Jlc3BvbnNlX2NiOworCXNjLT5zY19jbGVhbnVwID0gcmV3YXR0X3NlYXJjaF9jbGVhbnVw X2NiOworCXNjLT5zY19uZXh0ID0gb3AtPm9fY2FsbGJhY2s7CisgICAgICAgIHNjLT5zY19wcml2 YXRlID0gY2k7CisJb3AtPm9fY2FsbGJhY2sgPSBzYzsKKworCXJldHVybiBTTEFQX0NCX0NPTlRJ TlVFOworCit9CitzdGF0aWMgaW50CityZXdhdHRfZGJfZGVzdHJveSgKKyAgICAgICAgQmFja2Vu ZERCICpiZSwKKyAgICAgICAgQ29uZmlnUmVwbHkgKmNyICkKK3sKKyAgICAgICAgc2xhcF9vdmVy aW5zdCAqb24gPSAoc2xhcF9vdmVyaW5zdCAqKWJlLT5iZF9pbmZvOworCisgICAgICAgIG9uLT5v bl9iaS5iaV9wcml2YXRlID0gTlVMTDsKKworICAgICAgICByZXR1cm4gMDsKK30KKworc3RhdGlj IHNsYXBfb3Zlcmluc3QgcmV3YXR0X292bDsKKworc3RhdGljIENvbmZpZ0RyaXZlciAgICAgcmV3 YXR0X2NmZ2VuOworCitzdGF0aWMgQ29uZmlnVGFibGUgcmV3YXR0X2NmZ1tdID0geworCXsgInJh X2F0dHJpYnV0ZSIsIE5VTEwsIDIsIDIsIDAsIEFSR19NQUdJQ3xSRVdBVFRfQVRUUklCVVRFLAor CQlyZXdhdHRfY2ZnZW4sICIoT0xjZmdDdEF0OjIyLjEgTkFNRSAnb2xjUmV3YXR0QXR0cmlidXRl JyAiCisJCQkiREVTQyAnQXR0cmlidXRlIE5hbWUnICIKKwkJCSJFUVVBTElUWSBjYXNlSWdub3Jl TWF0Y2ggIgorCQkJIlNZTlRBWCBPTXNEaXJlY3RvcnlTdHJpbmcgIgorCQkJIlgtT1JERVJFRCAn VkFMVUVTJyApIiwgTlVMTCwgTlVMTCB9LAorCXsgInJhX3JlZ2V4IiwgTlVMTCwgMiwgMiwgMCwg QVJHX01BR0lDfFJFV0FUVF9SRUdFWCwKKwkJcmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi4y IE5BTUUgJ29sY1Jld2F0dFJlZ2V4JyAiCisJCQkiREVTQyAnUmVnZXgnICIKKwkJCSJTWU5UQVgg T01zRGlyZWN0b3J5U3RyaW5nICIKKwkJCSJYLU9SREVSRUQgJ1ZBTFVFUycgKSIsIE5VTEwsIE5V TEwgfSwKKwl7ICJyYV9zdWIiLCBOVUxMLCAxLCAyLCAwLCBBUkdfTUFHSUN8UkVXQVRUX1NVQiwK KwkJcmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi4zIE5BTUUgJ29sY1Jld2F0dFN1YicgIgor CQkJIkRFU0MgJ1N1YnN0aXR1dGlvbicgIgorCQkJIlNZTlRBWCBPTXNEaXJlY3RvcnlTdHJpbmcg IgorCQkJIlgtT1JERVJFRCAnVkFMVUVTJyApIiwgTlVMTCwgTlVMTCB9LAorCXsgInJhX2F0dHJp YnV0ZV90IiwgTlVMTCwgMiwgMiwgMCwgQVJHX01BR0lDfFJFV0FUVF9BVFRSSUJVVEVfVCwKKwkJ cmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi40IE5BTUUgJ29sY1Jld2F0dEF0dHJpYnV0ZVQn ICIKKwkJCSJERVNDICdUcmlnZ2VyaW5nIEF0dHJpYnV0ZSBOYW1lJyAiCisJCQkiU1lOVEFYIE9N c0RpcmVjdG9yeVN0cmluZyAiCisJCQkiWC1PUkRFUkVEICdWQUxVRVMnICkiLCBOVUxMLCBOVUxM IH0sCisJeyAicmFfcmVnZXhfdCIsIE5VTEwsIDIsIDIsIDAsIEFSR19NQUdJQ3xSRVdBVFRfUkVH RVhfVCwKKwkJcmV3YXR0X2NmZ2VuLCAiKE9MY2ZnQ3RBdDoyMi41IE5BTUUgJ29sY1Jld2F0dFJl Z2V4VCcgIgorCQkJIkRFU0MgJ1RyaWdnZXJpbmcgUmVnZXgnICIKKwkJCSJTWU5UQVggT01zRGly ZWN0b3J5U3RyaW5nICIKKwkJCSJYLU9SREVSRUQgJ1ZBTFVFUycgKSIsIE5VTEwsIE5VTEwgfSwK Kwl7IE5VTEwsIE5VTEwsIDAsIDAsIDAsIEFSR19JR05PUkVEIH0KK307CisKK3N0YXRpYyBDb25m aWdPQ3MgcmV3YXR0X29jc1tdID0geworCXsgIiggT0xjZmdDdE9jOjIyLjEgIgorCSAgIk5BTUUg J29sY1Jld2F0dENvbmZpZycgIgorCSAgIkRFU0MgJ0F0dHJpYnV0ZSBSZXdhdHQgY29uZmlndXJh dGlvbicgIgorCSAgIlNVUCBvbGNPdmVybGF5Q29uZmlnICIKKwkgICJNVVNUICggb2xjUmV3YXR0 QXR0cmlidXRlICQgb2xjUmV3YXR0UmVnZXgpICIgCisJICAiTUFZICggb2xjUmV3YXR0UmVnZXhU ICQgb2xjUmV3YXR0U3ViICQgb2xjUmV3YXR0QXR0cmlidXRlVCApICIgCisJICAiICkgIiwgCisJ ICBDZnRfT3ZlcmxheSwgcmV3YXR0X2NmZyB9LAorCXsgTlVMTCwgMCwgTlVMTCB9Cit9OworCitz dGF0aWMgaW50CityZXdhdHRfaW5pdGlhbGl6ZSggdm9pZCApIHsKKwlpbnQgcmM7CisJcmV3YXR0 X292bC5vbl9iaS5iaV90eXBlID0gInJld2F0dCI7CisKKwlyZXdhdHRfb3ZsLm9uX2JpLmJpX2Ri X2Rlc3Ryb3kgPSByZXdhdHRfZGJfZGVzdHJveTsKKwlyZXdhdHRfb3ZsLm9uX2JpLmJpX29wX3Nl YXJjaCA9IHJld2F0dF9zZWFyY2g7CisJcmV3YXR0X292bC5vbl9iaS5iaV9jZl9vY3MgPSByZXdh dHRfb2NzOworCQorCURlYnVnKCBMREFQX0RFQlVHX1RSQUNFLCAicmV3YXR0X2luaXRpYWxpemU6 IHJld2F0dF9vdmwub25fYmkuYmlfdHlwZT0gICVzXG4iLCByZXdhdHRfb3ZsLm9uX2JpLmJpX3R5 cGUgLCAwLDAgKTsKKwlyYyA9IGNvbmZpZ19yZWdpc3Rlcl9zY2hlbWEgKCByZXdhdHRfY2ZnLHJl d2F0dF9vY3MgKTsKKwlpZiAoIHJjICkgCisJCXJldHVybiByYzsKKwlyZXR1cm4gb3ZlcmxheV9y ZWdpc3RlciggJnJld2F0dF9vdmwgKTsKK30KKworaW50IGluaXRfbW9kdWxlKGludCBhcmdjLCBj aGFyICphcmd2W10pIHsKKwlyZXR1cm4gcmV3YXR0X2luaXRpYWxpemUoKTsKK30KKwotLSAKMS43 LjUuNAoK --=_c864110a076fc513331e0370bcb9adbe--

1 0

(ITS#7631) Overlay to rewrite value of attribute using regex
by bart＠icm.edu.pl 24 Jun '13

24 Jun '13

Full_Name: Dominik Bartkiewicz Version: OS: Linux URL: Submission from: (NULL) (89.73.105.138) A simple overlay allows override attribute values. In our case, it we replicate users date from three different servers and we wanted to override attributes such as homeDirectory, shell. a sample config: overlay rewatt ra_attribute homeDirectory ra_regex "home/(users|staff|guest)" ra_sub "icm/hydra/home/local" DB

1 0

Re: (ITS#7627) [Patch] Fix segfault in slaptest
by hyc＠symas.com 23 Jun '13

23 Jun '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/slaptest/0001-Fix-segfault-in-sla… > Submission from: (NULL) (209.132.186.34) > > > Consider the following configuration: > http://jsynacek.fedorapeople.org/openldap/slaptest/slapd-segfault.conf > > When an overlay is specified after the 'database monitor', slaptest segfaults. > I'm not sure whether such configuration makes much sense, however I think that > slaptest shouldn't segfault. > > To reproduce, use the above config and run: > slapd -Tt -f slapd-segfault.conf -F /path/to/a/dir Unable to reproduce any of this. No crash, and no uninit'd memory references in valgrind. I think something is corrupted in your source or build tree. > > Backtrace: > #0 0x0000003385009b70 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0 > #1 0x00007ffff7da524d in ldap_pvt_thread_mutex_lock (mutex=0x25) at > thr_posix.c:296 > #2 0x00000000005574b9 in monitor_cache_get (mi=0x1d, ndn=0x7fffffffde30, > ep=0x7fffffffde28) at cache.c:161 > #3 0x000000000051a10d in monitor_back_unregister_entry_attrs (ndn_in=0x908230, > target_a=0x0, target_cb=0xa70030, > nbase=0x0, scope=0, filter=0x0) at init.c:1520 > #4 0x000000000051a5b0 in monitor_back_unregister_entry_callback (ndn=0x908230, > cb=0xa70030, nbase=0x0, scope=0, > filter=0x0) at init.c:1632 > #5 0x00000000004f6f19 in bdb_monitor_db_close (be=0x907d70) at monitor.c:500 > #6 0x00000000004ef0b4 in bdb_db_close (be=0x907d70, cr=0x0) at init.c:595 > #7 0x0000000000454ad5 in backend_shutdown (be=0x907d70) at backend.c:383 > #8 0x00000000004814a9 in slap_shutdown (be=0x0) at init.c:232 > #9 0x00000000004de90d in slap_tool_destroy () at slapcommon.c:936 > #10 0x00000000004e0435 in slaptest (argc=6, argv=0x7fffffffe228) at > slaptest.c:116 > #11 0x000000000041a9f5 in main (argc=6, argv=0x7fffffffe228) at main.c:665 > > Notice the corrupt 'mi' pointer in frame #2. > > The segfault does not always appear, so here is the corresponding valgrind > output: > ==6751== Memcheck, a memory error detector > ==6751== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. > ==6751== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info > ==6751== Command: /home/jsynacek/work/2-upstream/openldap-git/servers/slapd/.libs/lt-slapd > -Tt -f slapd-segfault.conf -F ./testconf > ==6751== > 51c1a34e bdb_db_open: database "dc=example,dc=com": unclean shutdown detected; > attempting recovery. > 51c1a34e bdb_db_open: warning - no DB_CONFIG file found in directory > /var/lib/ldap: (2). > Expect poor performance for suffix "dc=example,dc=com". > 51c1a34e bdb_db_open: database "dc=example,dc=com": recovery skipped in > read-only mode. Run manual recovery if errors are encountered. > config file testing succeeded > ==6751== Conditional jump or move depends on uninitialised value(s) > ==6751== at 0x519E9D: monitor_back_unregister_entry_attrs (init.c:1473) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== > ==6751== Conditional jump or move depends on uninitialised value(s) > ==6751== at 0x5573EA: monitor_cache_get (cache.c:150) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== > ==6751== Use of uninitialised value of size 8 > ==6751== at 0x3385009B70: pthread_mutex_lock (in > /usr/lib64/libpthread-2.16.so) > ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) > ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== > ==6751== Invalid read of size 4 > ==6751== at 0x3385009B70: pthread_mutex_lock (in > /usr/lib64/libpthread-2.16.so) > ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) > ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== Address 0x37 is not stack'd, malloc'd or (recently) free'd > ==6751== > ==6751== > ==6751== Process terminating with default action of signal 11 (SIGSEGV) > ==6751== Access not within mapped region at address 0x37 > ==6751== at 0x3385009B70: pthread_mutex_lock (in > /usr/lib64/libpthread-2.16.so) > ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) > ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) > ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) > ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) > ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) > ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) > ==6751== by 0x454AD4: backend_shutdown (backend.c:383) > ==6751== by 0x4814A8: slap_shutdown (init.c:232) > ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) > ==6751== by 0x4E0434: slaptest (slaptest.c:116) > ==6751== by 0x41A9F4: main (main.c:665) > ==6751== If you believe this happened as a result of a stack > ==6751== overflow in your program's main thread (unlikely but > ==6751== possible), you can try to increase the size of the > ==6751== main thread stack using the --main-stacksize= flag. > ==6751== The main thread stack size used in this run was 8388608. > ==6751== > ==6751== HEAP SUMMARY: > ==6751== in use at exit: 1,784,260 bytes in 10,532 blocks > ==6751== total heap usage: 20,806 allocs, 10,274 frees, 4,333,045 bytes > allocated > ==6751== > ==6751== LEAK SUMMARY: > ==6751== definitely lost: 16 bytes in 1 blocks > ==6751== indirectly lost: 0 bytes in 0 blocks > ==6751== possibly lost: 0 bytes in 0 blocks > ==6751== still reachable: 1,784,244 bytes in 10,531 blocks > ==6751== suppressed: 0 bytes in 0 blocks > ==6751== Rerun with --leak-check=full to see details of leaked memory > ==6751== > ==6751== For counts of detected and suppressed errors, rerun with: -v > ==6751== Use --track-origins=yes to see where uninitialised values come from > ==6751== ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 2 from 2) > > I'm not sure if my patch is correct. I feel it's more like a workaround, so feel > free to modify it if that's the case. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7628) back-mdb bug with test064-constraint
by hyc＠symas.com 23 Jun '13

23 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: master, 7c6b599de6d7c0e10aa8bf6920ca07d94605e8c2 > OS: Linux amd64 > URL: > Submission from: (NULL) (129.240.203.186) > Submitted by: hallvard > > > id2entry.c:mdb_opinfo_get() renews a txn which is in use. It gets > EINVAL, which it does not catch. Caught by this patch and test064: Fixed now in master. I've left this assert in place as well, it obviously Should Never Happen. > > index 84de09d..a247974 100644 > --- a/servers/slapd/back-mdb/id2entry.c > +++ b/servers/slapd/back-mdb/id2entry.c > @@ -507,3 +507,4 @@ mdb_opinfo_get( Operation *op, struct mdb_info *mdb, int > rdonly, mdb_op_info **m > if ( renew ) { > - mdb_txn_renew( moi->moi_txn ); > + rc = mdb_txn_renew( moi->moi_txn ); > + assert(rc == MDB_SUCCESS); > } > > Core file in ada:/home/hallvard/openldap.g/tests/core. > > > > #2 0x00007ff6a1609301 in *__GI___assert_fail (assertion=0x601014 "rc == 0", > file=<value optimized out>, line=509, > function=0x601141 "mdb_opinfo_get") at assert.c:81 > #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, > rdonly=1, moip=0x7ff69e280d08) > at id2entry.c:509 > #4 0x00000000004f2bed in mdb_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at > search.c:343 > #5 0x00000000004c4f08 in overlay_op_walk (op=0x7ff69e411130, rs=0x7ff69e4112a0, > which=op_search, oi=0x15b30e0, on=0x0) > at backover.c:691 > #6 0x00000000004c511f in over_op_func (op=0x7ff69e411130, rs=0x7ff69e4112a0, > which=op_search) at backover.c:743 > #7 0x00000000004c5207 in over_op_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) > at backover.c:770 > #8 0x000000000052a197 in constraint_violation (c=0x15dc620, bv=0x1af6f90, > op=0x17c8cf0) at constraint.c:666 > #9 0x000000000052a82a in constraint_add (op=0x17c8cf0, rs=0x7ff69e411a60) at > constraint.c:812 > #10 0x00000000004c4e69 in overlay_op_walk (op=0x17c8cf0, rs=0x7ff69e411a60, > which=op_add, oi=0x15b30e0, on=0x15b32c0) > at backover.c:681 > #11 0x00000000004c511f in over_op_func (op=0x17c8cf0, rs=0x7ff69e411a60, > which=op_add) at backover.c:743 > #12 0x00000000004c52af in over_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at > backover.c:794 > #13 0x000000000043aa44 in fe_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at > add.c:334 > #14 0x000000000043a341 in do_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:194 > #15 0x0000000000430da3 in connection_operation (ctx=0x7ff69e411b90, > arg_v=0x17c8cf0) at connection.c:1155 > #16 0x0000000000431344 in connection_read_thread (ctx=0x7ff69e411b90, argv=0xb) > at connection.c:1291 > #17 0x00000000005953c5 in ldap_int_thread_pool_wrapper (xpool=0x1543920) at > tpool.c:688 > > > (gdb) frame 3 > #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, > rdonly=1, moip=0x7ff69e280d08) > at id2entry.c:509 > 509 assert(rc == MDB_SUCCESS); > (gdb) info locals > rc = 22 > renew = 1 > data = 0x1af36b0 > ctx = 0x7ff69e411b90 > moi = 0x7ff69e280d10 > oex = 0x0 > __PRETTY_FUNCTION__ = "mdb_opinfo_get" > (gdb) p *moi > $1 = {moi_oe = {oe_next = {sle_next = 0x7ff69e411850}, oe_key = 0x7ff6a2a02010}, > moi_txn = 0x1af36b0, moi_ref = 0, > moi_flag = 1 '\001'} > (gdb) p *moi->moi_txn > $2 = {mt_parent = 0x0, mt_child = 0x0, mt_next_pgno = 31, mt_txnid = 51, mt_env > = 0x17c0920, mt_free_pgs = 0x0, > mt_u = {dirty_list = 0x7ff6a2bd5080, reader = 0x7ff6a2bd5080}, mt_dbxs = > 0x17baa80, mt_dbs = 0x1af3718, > mt_cursors = 0x0, mt_dbflags = 0x1af4f78 "\b\b\n\b\b\b\n\n\n\n\n", mt_numdbs = > 11, mt_flags = 1, mt_dirty_room = 0, > mt_toggle = 1} > > The EINVAL was returned because mt_dbxs != NULL. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6970)
by michael＠stroeder.com 19 Jun '13

19 Jun '13

breuil(a)craig.fr wrote: > after being adviced to try with mdb backend instead, which doesnt use > locking, slapd exploded as soon as i had enabled the memberOf & > autoGroup overlays and one client tried to connect to the server: The last release you mentioned in this ITS was 2.4.31. Is that the version you're still using? You should not use back-mdb with this release. Use at least 2.4.35 or better current RE24 from git repo. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;h=refs/heads… Ciao, Michael.

1 0

(ITS#7628) back-mdb bug with test064-constraint
by h.b.furuseth＠usit.uio.no 19 Jun '13

19 Jun '13

Full_Name: Hallvard B Furuseth Version: master, 7c6b599de6d7c0e10aa8bf6920ca07d94605e8c2 OS: Linux amd64 URL: Submission from: (NULL) (129.240.203.186) Submitted by: hallvard id2entry.c:mdb_opinfo_get() renews a txn which is in use. It gets EINVAL, which it does not catch. Caught by this patch and test064: index 84de09d..a247974 100644 --- a/servers/slapd/back-mdb/id2entry.c +++ b/servers/slapd/back-mdb/id2entry.c @@ -507,3 +507,4 @@ mdb_opinfo_get( Operation *op, struct mdb_info *mdb, int rdonly, mdb_op_info **m if ( renew ) { - mdb_txn_renew( moi->moi_txn ); + rc = mdb_txn_renew( moi->moi_txn ); + assert(rc == MDB_SUCCESS); } Core file in ada:/home/hallvard/openldap.g/tests/core. #2 0x00007ff6a1609301 in *__GI___assert_fail (assertion=0x601014 "rc == 0", file=<value optimized out>, line=509, function=0x601141 "mdb_opinfo_get") at assert.c:81 #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, rdonly=1, moip=0x7ff69e280d08) at id2entry.c:509 #4 0x00000000004f2bed in mdb_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at search.c:343 #5 0x00000000004c4f08 in overlay_op_walk (op=0x7ff69e411130, rs=0x7ff69e4112a0, which=op_search, oi=0x15b30e0, on=0x0) at backover.c:691 #6 0x00000000004c511f in over_op_func (op=0x7ff69e411130, rs=0x7ff69e4112a0, which=op_search) at backover.c:743 #7 0x00000000004c5207 in over_op_search (op=0x7ff69e411130, rs=0x7ff69e4112a0) at backover.c:770 #8 0x000000000052a197 in constraint_violation (c=0x15dc620, bv=0x1af6f90, op=0x17c8cf0) at constraint.c:666 #9 0x000000000052a82a in constraint_add (op=0x17c8cf0, rs=0x7ff69e411a60) at constraint.c:812 #10 0x00000000004c4e69 in overlay_op_walk (op=0x17c8cf0, rs=0x7ff69e411a60, which=op_add, oi=0x15b30e0, on=0x15b32c0) at backover.c:681 #11 0x00000000004c511f in over_op_func (op=0x17c8cf0, rs=0x7ff69e411a60, which=op_add) at backover.c:743 #12 0x00000000004c52af in over_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at backover.c:794 #13 0x000000000043aa44 in fe_op_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:334 #14 0x000000000043a341 in do_add (op=0x17c8cf0, rs=0x7ff69e411a60) at add.c:194 #15 0x0000000000430da3 in connection_operation (ctx=0x7ff69e411b90, arg_v=0x17c8cf0) at connection.c:1155 #16 0x0000000000431344 in connection_read_thread (ctx=0x7ff69e411b90, argv=0xb) at connection.c:1291 #17 0x00000000005953c5 in ldap_int_thread_pool_wrapper (xpool=0x1543920) at tpool.c:688 (gdb) frame 3 #3 0x0000000000515db1 in mdb_opinfo_get (op=0x7ff69e411130, mdb=0x7ff6a2a02010, rdonly=1, moip=0x7ff69e280d08) at id2entry.c:509 509 assert(rc == MDB_SUCCESS); (gdb) info locals rc = 22 renew = 1 data = 0x1af36b0 ctx = 0x7ff69e411b90 moi = 0x7ff69e280d10 oex = 0x0 __PRETTY_FUNCTION__ = "mdb_opinfo_get" (gdb) p *moi $1 = {moi_oe = {oe_next = {sle_next = 0x7ff69e411850}, oe_key = 0x7ff6a2a02010}, moi_txn = 0x1af36b0, moi_ref = 0, moi_flag = 1 '\001'} (gdb) p *moi->moi_txn $2 = {mt_parent = 0x0, mt_child = 0x0, mt_next_pgno = 31, mt_txnid = 51, mt_env = 0x17c0920, mt_free_pgs = 0x0, mt_u = {dirty_list = 0x7ff6a2bd5080, reader = 0x7ff6a2bd5080}, mt_dbxs = 0x17baa80, mt_dbs = 0x1af3718, mt_cursors = 0x0, mt_dbflags = 0x1af4f78 "\b\b\n\b\b\b\n\n\n\n\n", mt_numdbs = 11, mt_flags = 1, mt_dirty_room = 0, mt_toggle = 1} The EINVAL was returned because mt_dbxs != NULL.

1 0

(ITS#6970)
by breuil＠craig.fr 19 Jun '13

19 Jun '13

Hi, after being adviced to try with mdb backend instead, which doesnt use locking, slapd exploded as soon as i had enabled the memberOf & autoGroup overlays and one client tried to connect to the server: 51c1b560 => mdb_search 51c1b560 mdb_dn2entry("dc=myorg") 51c1b560 => mdb_dn2id("dc=myorg") 51c1b560 <= mdb_dn2id: got id=0x1 51c1b560 => mdb_entry_decode: 51c1b560 <= mdb_entry_decode Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffb1fd3700 (LWP 15475)] autogroup_response (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at autogroup.c:927 927 autogroup_def_t *agd = agi->agi_def; (gdb) bt #0 autogroup_response (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at autogroup.c:927 #1 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/backover.c:237 #2 0x00007ffff7f227d6 in slap_response_play (op=op@entry=0x7ffff82d52b0, rs=rs@entry=0x7fffb1fd2a50) at ../../../../servers/slapd/result.c:507 #3 0x00007ffff7f25261 in slap_send_search_entry (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/result.c:1008 #4 0x00007ffff3213600 in mdb_search (op=0x7ffff82d52b0, rs=<optimized out>) at ../../../../../servers/slapd/back-mdb/search.c:852 #5 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82d52b0, rs=0x7fffb1fd2a50, which=op_search, oi=0x7ffff82e6e50, on=0x0) at ../../../../servers/slapd/backover.c:671 #6 0x00007ffff7f8031b in over_op_func (op=0x7ffff82d52b0, rs=<optimized out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723 #7 0x00007ffff7f15641 in fe_op_search (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/search.c:402 #8 0x00007ffff7f14f06 in do_search (op=0x7ffff82d52b0, rs=0x7fffb1fd2a50) at ../../../../servers/slapd/search.c:247 #9 0x00007ffff7f12961 in connection_operation (ctx=ctx@entry=0x7fffb1fd2ba0, arg_v=arg_v@entry=0x7ffff82d52b0) at ../../../../servers/slapd/connection.c:1150 #10 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7fffb1fd2ba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286 #11 0x00007ffff7a73ff3 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #12 0x00007ffff5c66b50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #13 0x00007ffff59b0a7d in clone () from /lib/x86_64-linux-gnu/libc.so.6 #14 0x0000000000000000 in ?? () (gdb) p agi $1 = (autogroup_info_t *) 0x0 So mdb doesnt seem to be an option here... -- Landry Breuil Mouton a 5 pattes du CRAIG

1 0

(ITS#7627) [Patch] Fix segfault in slaptest
by jsynacek＠redhat.com 19 Jun '13

19 Jun '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/slaptest/0001-Fix-segfault-in-sla… Submission from: (NULL) (209.132.186.34) Consider the following configuration: http://jsynacek.fedorapeople.org/openldap/slaptest/slapd-segfault.conf When an overlay is specified after the 'database monitor', slaptest segfaults. I'm not sure whether such configuration makes much sense, however I think that slaptest shouldn't segfault. To reproduce, use the above config and run: slapd -Tt -f slapd-segfault.conf -F /path/to/a/dir Backtrace: #0 0x0000003385009b70 in pthread_mutex_lock () from /usr/lib64/libpthread.so.0 #1 0x00007ffff7da524d in ldap_pvt_thread_mutex_lock (mutex=0x25) at thr_posix.c:296 #2 0x00000000005574b9 in monitor_cache_get (mi=0x1d, ndn=0x7fffffffde30, ep=0x7fffffffde28) at cache.c:161 #3 0x000000000051a10d in monitor_back_unregister_entry_attrs (ndn_in=0x908230, target_a=0x0, target_cb=0xa70030, nbase=0x0, scope=0, filter=0x0) at init.c:1520 #4 0x000000000051a5b0 in monitor_back_unregister_entry_callback (ndn=0x908230, cb=0xa70030, nbase=0x0, scope=0, filter=0x0) at init.c:1632 #5 0x00000000004f6f19 in bdb_monitor_db_close (be=0x907d70) at monitor.c:500 #6 0x00000000004ef0b4 in bdb_db_close (be=0x907d70, cr=0x0) at init.c:595 #7 0x0000000000454ad5 in backend_shutdown (be=0x907d70) at backend.c:383 #8 0x00000000004814a9 in slap_shutdown (be=0x0) at init.c:232 #9 0x00000000004de90d in slap_tool_destroy () at slapcommon.c:936 #10 0x00000000004e0435 in slaptest (argc=6, argv=0x7fffffffe228) at slaptest.c:116 #11 0x000000000041a9f5 in main (argc=6, argv=0x7fffffffe228) at main.c:665 Notice the corrupt 'mi' pointer in frame #2. The segfault does not always appear, so here is the corresponding valgrind output: ==6751== Memcheck, a memory error detector ==6751== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==6751== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==6751== Command: /home/jsynacek/work/2-upstream/openldap-git/servers/slapd/.libs/lt-slapd -Tt -f slapd-segfault.conf -F ./testconf ==6751== 51c1a34e bdb_db_open: database "dc=example,dc=com": unclean shutdown detected; attempting recovery. 51c1a34e bdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=example,dc=com". 51c1a34e bdb_db_open: database "dc=example,dc=com": recovery skipped in read-only mode. Run manual recovery if errors are encountered. config file testing succeeded ==6751== Conditional jump or move depends on uninitialised value(s) ==6751== at 0x519E9D: monitor_back_unregister_entry_attrs (init.c:1473) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== ==6751== Conditional jump or move depends on uninitialised value(s) ==6751== at 0x5573EA: monitor_cache_get (cache.c:150) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== ==6751== Use of uninitialised value of size 8 ==6751== at 0x3385009B70: pthread_mutex_lock (in /usr/lib64/libpthread-2.16.so) ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== ==6751== Invalid read of size 4 ==6751== at 0x3385009B70: pthread_mutex_lock (in /usr/lib64/libpthread-2.16.so) ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== Address 0x37 is not stack'd, malloc'd or (recently) free'd ==6751== ==6751== ==6751== Process terminating with default action of signal 11 (SIGSEGV) ==6751== Access not within mapped region at address 0x37 ==6751== at 0x3385009B70: pthread_mutex_lock (in /usr/lib64/libpthread-2.16.so) ==6751== by 0x4C2524C: ldap_pvt_thread_mutex_lock (thr_posix.c:296) ==6751== by 0x5574B8: monitor_cache_get (cache.c:161) ==6751== by 0x51A10C: monitor_back_unregister_entry_attrs (init.c:1520) ==6751== by 0x51A5AF: monitor_back_unregister_entry_callback (init.c:1632) ==6751== by 0x4F6F18: bdb_monitor_db_close (monitor.c:500) ==6751== by 0x4EF0B3: bdb_db_close (init.c:595) ==6751== by 0x454AD4: backend_shutdown (backend.c:383) ==6751== by 0x4814A8: slap_shutdown (init.c:232) ==6751== by 0x4DE90C: slap_tool_destroy (slapcommon.c:936) ==6751== by 0x4E0434: slaptest (slaptest.c:116) ==6751== by 0x41A9F4: main (main.c:665) ==6751== If you believe this happened as a result of a stack ==6751== overflow in your program's main thread (unlikely but ==6751== possible), you can try to increase the size of the ==6751== main thread stack using the --main-stacksize= flag. ==6751== The main thread stack size used in this run was 8388608. ==6751== ==6751== HEAP SUMMARY: ==6751== in use at exit: 1,784,260 bytes in 10,532 blocks ==6751== total heap usage: 20,806 allocs, 10,274 frees, 4,333,045 bytes allocated ==6751== ==6751== LEAK SUMMARY: ==6751== definitely lost: 16 bytes in 1 blocks ==6751== indirectly lost: 0 bytes in 0 blocks ==6751== possibly lost: 0 bytes in 0 blocks ==6751== still reachable: 1,784,244 bytes in 10,531 blocks ==6751== suppressed: 0 bytes in 0 blocks ==6751== Rerun with --leak-check=full to see details of leaked memory ==6751== ==6751== For counts of detected and suppressed errors, rerun with: -v ==6751== Use --track-origins=yes to see where uninitialised values come from ==6751== ERROR SUMMARY: 11 errors from 9 contexts (suppressed: 2 from 2) I'm not sure if my patch is correct. I feel it's more like a workaround, so feel free to modify it if that's the case.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs