- openldap-bugs - openldap.org

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 03 Jun '19

03 Jun '19

--_000_AM0PR0202MB35530E1160E3DCDDFBD1D06ABA140AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGVsbG8gT25kxZllaiwNCg0Kc29ycnkgdG8gYW5zd2VyIHNvIGxhdGUsIEkgd2FzIG9mZiAoc2lj aykuDQoNCg0KQW5zd2VyaW5nIHlvdXIgcXVlc3Rpb25zOg0KDQoNCkkgZGlkbid0IHRyeSB0byBy ZXByb2R1Y2UgdGhlIGNyYXNoIG9uIGEgZGlmZmVyZW50IHN5c3RlbS4NCg0KV2hhdCBpcyB0aGUg Z29hbCBvZiBpbnN0YWxsaW5nIGFuIG5ldyB2ZXJzaW9uIG9mIGdkYiBvbiBteSBzeXN0ZW0gPyBJ IGFtIG5vdCBzdXJlIGl0IHdpbGwgYmUgZWFzeSB0byBwcm9jZWVkLg0KDQpGb2xsb3dpbmcgeW91 ciBhZHZpc2UsIEkgaGF2ZSBjb3JyZWN0ZWQgdGhlIGNoYWluIGNvbmZpZ3VyYXRpb24gd2l0aCBy ZW1vdmluZyBtb2RlPXNlbGYsIGJ1dCBpdCBkaWRuJ3QgY2hhbmdlIG5vdGhpbmcgcmVnYXJkaW5n IHRoZSBjcmFzaC4NCg0KDQpkbyB5b3UgdGhpbmsgaXQgY291bGQgYmUgcG9zc2libGUgdGhhdCB0 aGUgZ2xpYmMgY29udGFpbnMgYnVncyByZXN1bHRpbmcgdGhhdCBjcmFzaD8NCg0KDQpJIGRvIG5v dCBrbm93IHdoYXQgdG8gZG8uIFdvdWxkIGl0IGJlIHJlbGV2YW50IHRvIHVwZ3JhZGUgdGhlIE9T Pw0KDQoNCmtpbmQgcmVnYXJkcw0KDQoNCkplYW4tUGhpbGlwcGUgQXlhbmlkZXMNCkNvbmNlcHRp b24gZXQgYXJjaGl0ZWN0dXJlIHPDqWN1cml0w6kNClNlcnZpY2UgJiBPcGVyYXRpb24gLyBJbmZy YXN0cnVjdHVyZSBOZXR3b3JrIFNlY3VyaXR5IEJhY2tib25lDQp0w6lsICszMzEzNDQ5MDYyOA0K UHJvc29kaWUtQ2FwZ2VtaW5pDQpQZW9wbGUgbWF0dGVyLCByZXN1bHRzIGNvdW50Lg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkRlIDogT25kxZllaiBLdXpuw61rIDxvbmRyYUBt aXN0b3RlYmUubmV0Pg0KRW52b3nDqSA6IGx1bmRpIDIwIG1haSAyMDE5IDE2OjE1OjMxDQrDgCA6 IEFZQU5JREVTLCBKRUFOLVBISUxJUFBFDQpDYyA6IG9wZW5sZGFwLWl0c0BPcGVuTERBUC5vcmcN Ck9iamV0IDogUmU6IChJVFMjOTAyMykgY3Jhc2ggdXNpbmcgcHBvbGljeSBjaGFpbmluZyBmcm9t IHNsYXZlIHRvIG1hc3Rlcg0KDQpPbiBNb24sIE1heSAyMCwgMjAxOSBhdCAxMDoyOTowMkFNICsw MDAwLCBBWUFOSURFUywgSkVBTi1QSElMSVBQRSB3cm90ZToNCj4gWWVzLCBpdCBzZXJ2ZXMgdHJh ZmZpYy4gSXQgZG9lc24ndCBjcmFzaCB1bnRpbCBJIHJ1biBhIGJpbmQgd2l0aCBhDQo+IHdyb25n IHBhc3N3b3JkLg0KPg0KPj4gKGdkYikgY29udA0KPj4gQ29udGludWluZy4NCj4NCj4gW0xEQVAg c2VhcmNoIHdpdGggd3JvbmcgcGFzc3dvcmRdDQo+DQo+PiBbTmV3IFRocmVhZCAtMTIzNzU0MTk2 OCAoTFdQIDI5MzgwKV0NCj4NCj4+IFByb2dyYW0gZXhpdGVkIHdpdGggY29kZSAwMTc3Lg0KPj4g KGdkYikgdGhyZWFkIGFwcGx5IGFsbCBidCBmdWxsDQo+DQo+IFllcyBzb3JyeSwgSXQgcnVucyBv biBhbiBvbGQgdmVyc2lvbiBvZiBkZWJpYW46IDQ6MCAzMiBiaXRzIHRoYXQgSSBhbQ0KPiBub3Qg YXV0aG9yaXNlZCB0byB1cGdyYWRlLg0KPg0KPiBJdCB0aGUgZmlyc3QgdGltZSB3ZSByZWNvcmQg dGhhdCBzb3J0IG9mIGlzc3VlIG9uIHRoYXQgcGxhdGZvcm3igKYNCg0KSGkgSmVhbi1QaGlsaXBw ZSwNCmFyZSB5b3UgYWJsZSB0byByZXByb2R1Y2UgdGhpcyBvbiBhIGRpZmZlcmVudCBzeXN0ZW0s IGlmIG5vdCwgY2FuIHlvdQ0KZ2V0IGEgbW9yZSByZWNlbnQgZ2RiIG9uIHRoYXQgc3lzdGVtPw0K DQpJIGhhdmUgdHJpZWQgdG8gcmVwcm9kdWNlIHdpdGggYSBjb25maWcgc2ltaWxhciB0byB0aGUg b25lIHlvdSBkZXNjcmliZQ0KZGlkbid0IG1hbmFnZSB0byBwcm92b2tlIGEgc2VnZmF1bHQgd2l0 aCByZTI0IG5vciBtYXN0ZXIuDQoNCk9uIGEgc2lkZSBub3RlLCBJIGRvbid0IHRoaW5rIHJ1bm5p bmcgdGhlIGNoYWluIG92ZXJsYXkgd2l0aCBtb2RlPXNlbGYNCndpbGwgd29yayB0byBwcm9wYWdh dGUgdGhlIHBwb2xpY3kgaW5mb3JtYXRpb24gdGhlIHdheSB5b3Ugd2FudC4gVGhlDQpzYW1lIGZh aWxpbmcgY3JlZGVudGlhbHMgd2lsbCBiZSB1c2VkIHRvIGNvbnRhY3QgdGhlIHVwc3RyZWFtIHNl cnZlciBhbmQNCnNvIHRoZSBpbml0aWFsIGJpbmQgd2lsbCBiZSByZWplY3RlZCBhZ2Fpbiwgbm90 IGFsbG93aW5nIHRoZQ0KbW9kaWZpY2F0aW9uIHRvIGJlIHBlcmZvcm1lZC4NCg0KUmVnYXJkcywN Cg0KLS0NCk9uZMWZZWogS3V6bsOtaw0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVyDQpTeW1hcyBD b3Jwb3JhdGlvbiAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NClBh Y2thZ2VkLCBjZXJ0aWZpZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBi eSBPcGVuTERBUA0KVGhpcyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENh cGdlbWluaSBHcm91cC4gSXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9t IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg eW91IGFyZSBub3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNz ZW1pbmF0ZSwgZGlzdHJpYnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVy ZW9mLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNz YWdlLgo= --_000_AM0PR0202MB35530E1160E3DCDDFBD1D06ABA140AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5IZWxsbyA8Zm9udCBzaXplPSIyIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExcHQ7Ij5PbmTFmWVqLDwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTFwdDsiPnNvcnJ5IHRvIGFuc3dlciBzbyBsYXRlLCBJIHdhcyBvZmYg KHNpY2spLjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4t Ym90dG9tOjAiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPjxi cj4NCjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90 dG9tOjAiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPkFuc3dl cmluZyB5b3VyIHF1ZXN0aW9uczo8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t dG9wOjA7bWFyZ2luLWJvdHRvbTowIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExcHQ7Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9w OjA7bWFyZ2luLWJvdHRvbTowIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExcHQ7Ij5JIGRpZG4ndCB0cnkgdG8gcmVwcm9kdWNlIHRoZSBjcmFzaCBvbiBhIGRpZmZlcmVu dCBzeXN0ZW0uPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdp bi1ib3R0b206MCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+ V2hhdCBpcyB0aGUgZ29hbCBvZiBpbnN0YWxsaW5nIGFuIG5ldyB2ZXJzaW9uIG9mIGdkYiBvbiBt eSBzeXN0ZW0gPyBJIGFtIG5vdCBzdXJlIGl0IHdpbGwgYmUgZWFzeSB0byBwcm9jZWVkLjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPkZvbGxvd2luZyB5b3Vy IGFkdmlzZSwgSSBoYXZlIGNvcnJlY3RlZDwvc3Bhbj48L2ZvbnQ+IHRoZSBjaGFpbiBjb25maWd1 cmF0aW9uIHdpdGggcmVtb3ZpbmcgbW9kZT1zZWxmLCBidXQgaXQgZGlkbid0IGNoYW5nZSBub3Ro aW5nIHJlZ2FyZGluZyB0aGUgY3Jhc2guPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJn aW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJv dHRvbTowIj5kbyB5b3UgdGhpbmsgaXQgY291bGQgYmUgcG9zc2libGUgdGhhdCB0aGUgZ2xpYmMg Y29udGFpbnMgYnVncyByZXN1bHRpbmcgdGhhdCBjcmFzaD88YnI+DQo8L3A+DQo8cCBzdHlsZT0i bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdp bi10b3A6MDttYXJnaW4tYm90dG9tOjAiPkkgZG8gbm90IGtub3cgd2hhdCB0byBkby4gV291bGQg aXQgYmUgcmVsZXZhbnQgdG8gdXBncmFkZSB0aGUgT1M/PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7 bWFyZ2luLWJvdHRvbTowIj5raW5kIHJlZ2FyZHM8YnI+DQo8L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LXRvcDowO21hcmdpbi1ib3R0b206MCI+PGJyPg0KPC9wPg0KPGRpdiBpZD0iU2lnbmF0dXJlIj4N CjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1VVEYtOCI+DQo8ZGl2IGlkPSJkaXZ0 YWdkZWZhdWx0d3JhcHBlciIgZGlyPSJsdHIiIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBIZWx2ZXRpY2EsIHNhbnMtc2Vy aWYsICZxdW90O0Vtb2ppRm9udCZxdW90OywgJnF1b3Q7QXBwbGUgQ29sb3IgRW1vamkmcXVvdDss ICZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LCBOb3RvQ29sb3JFbW9qaSwgJnF1b3Q7U2Vnb2Ug VUkgU3ltYm9sJnF1b3Q7LCAmcXVvdDtBbmRyb2lkIEVtb2ppJnF1b3Q7LCBFbW9qaVN5bWJvbHM7 Ij4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIiBkaXI9Imx0ciIgc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fu cy1zZXJpZiwgJnF1b3Q7RW1vamlGb250JnF1b3Q7LCAmcXVvdDtBcHBsZSBDb2xvciBFbW9qaSZx dW90OywgJnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssIE5vdG9Db2xvckVtb2ppLCAmcXVvdDtT ZWdvZSBVSSBTeW1ib2wmcXVvdDssICZxdW90O0FuZHJvaWQgRW1vamkmcXVvdDssIEVtb2ppU3lt Ym9sczsiPg0KPHA+PHNwYW4gbGFuZz0iZnIiPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJtYXJn aW46MCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuLHNlcmlmIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEycHQiPjxmb250IHNpemU9IjIiIGZhY2U9IlZlcmRhbmEsc2Fucy1z ZXJpZiIgY29sb3I9IiMwMDQ2OEMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OXB0Ij48Yj5KZWFu LVBoaWxpcHBlIEF5YW5pZGVzPGJyPg0KPC9iPjwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjwvZm9udD48 L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGNvbG9yOmJsYWNrIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuNXB0OyBmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjpibGFjayI+Q29uY2VwdGlvbiBldCBhcmNoaXRlY3R1cmUg c8OpY3VyaXTDqTwvc3Bhbj48YnI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjhwdDsgZm9udC1m YW1pbHk6QXJpYWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPlNlcnZpY2UgJmFtcDsgT3BlcmF0aW9u IC8gSW5mcmFzdHJ1Y3R1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7IGZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 IGNvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjhwdDsgZm9udC1mYW1pbHk6QXJp YWwsSGVsdmV0aWNhLHNhbnMtc2VyaWYiPg0KIE5ldHdvcmsgU2VjdXJpdHkgQmFja2JvbmU8L3Nw YW4+PGJyPg0KPGEgY2xhc3M9Im8zNjVidXR0b24iIGlkPSJMUE5vTFAiPjxzcGFuIGNsYXNzPSJt cy1mb250LXMgbXMtZm9udC1jb2xvci10aGVtZVByaW1hcnkiIHRpdGxlPSImIzQzOzMzMTM0NDkw NjI4Ij50w6lsICYjNDM7MzMxMzQ0OTA2Mjg8L3NwYW4+PC9hPjxicj4NClByb3NvZGllLUNhcGdl bWluaTxicj4NCjwvc3Bhbj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBjb2xvcjojMDA5OENDIj5QZW9wbGUg bWF0dGVyLCByZXN1bHRzIGNvdW50Ljwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjxzdHJvbmc+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7IGNvbG9yOiMwMDk4Q0MiPjwvc3Bhbj48L3N0cm9uZz48L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8aHIgc3R5bGU9ImRpc3BsYXk6aW5saW5lLWJsb2NrO3dpZHRoOjk4JSIgdGFiaW5kZXg9 Ii0xIj4NCjxkaXYgaWQ9ImRpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBmYWNlPSJDYWxp YnJpLCBzYW5zLXNlcmlmIiBzdHlsZT0iZm9udC1zaXplOjExcHQiIGNvbG9yPSIjMDAwMDAwIj48 Yj5EZSA6PC9iPiBPbmTFmWVqIEt1em7DrWsgJmx0O29uZHJhQG1pc3RvdGViZS5uZXQmZ3Q7PGJy Pg0KPGI+RW52b3nDqSA6PC9iPiBsdW5kaSAyMCBtYWkgMjAxOSAxNjoxNTozMTxicj4NCjxiPsOA IDo8L2I+IEFZQU5JREVTLCBKRUFOLVBISUxJUFBFPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBvcGVu bGRhcC1pdHNAT3BlbkxEQVAub3JnPGJyPg0KPGI+T2JqZXQgOjwvYj4gUmU6IChJVFMjOTAyMykg Y3Jhc2ggdXNpbmcgcHBvbGljeSBjaGFpbmluZyBmcm9tIHNsYXZlIHRvIG1hc3RlcjwvZm9udD4N CjxkaXY+Jm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IkJvZHlGcmFnbWVudCI+PGZv bnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNzPSJQ bGFpblRleHQiPk9uIE1vbiwgTWF5IDIwLCAyMDE5IGF0IDEwOjI5OjAyQU0gJiM0MzswMDAwLCBB WUFOSURFUywgSkVBTi1QSElMSVBQRSB3cm90ZTo8YnI+DQomZ3Q7IFllcywgaXQgc2VydmVzIHRy YWZmaWMuIEl0IGRvZXNuJ3QgY3Jhc2ggdW50aWwgSSBydW4gYSBiaW5kIHdpdGggYTxicj4NCiZn dDsgd3JvbmcgcGFzc3dvcmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyAoZ2RiKSBjb250PGJy Pg0KJmd0OyZndDsgQ29udGludWluZy48YnI+DQomZ3Q7IDxicj4NCiZndDsgW0xEQVAgc2VhcmNo IHdpdGggd3JvbmcgcGFzc3dvcmRdPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBbTmV3IFRocmVh ZCAtMTIzNzU0MTk2OCAoTFdQIDI5MzgwKV08YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IFByb2dy YW0gZXhpdGVkIHdpdGggY29kZSAwMTc3Ljxicj4NCiZndDsmZ3Q7IChnZGIpIHRocmVhZCBhcHBs eSBhbGwgYnQgZnVsbDxicj4NCiZndDsgPGJyPg0KJmd0OyBZZXMgc29ycnksIEl0IHJ1bnMgb24g YW4gb2xkIHZlcnNpb24gb2YgZGViaWFuOiA0OjAgMzIgYml0cyB0aGF0IEkgYW08YnI+DQomZ3Q7 IG5vdCBhdXRob3Jpc2VkIHRvIHVwZ3JhZGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IHRoZSBm aXJzdCB0aW1lIHdlIHJlY29yZCB0aGF0IHNvcnQgb2YgaXNzdWUgb24gdGhhdCBwbGF0Zm9ybeKA pjxicj4NCjxicj4NCkhpIEplYW4tUGhpbGlwcGUsPGJyPg0KYXJlIHlvdSBhYmxlIHRvIHJlcHJv ZHVjZSB0aGlzIG9uIGEgZGlmZmVyZW50IHN5c3RlbSwgaWYgbm90LCBjYW4geW91PGJyPg0KZ2V0 IGEgbW9yZSByZWNlbnQgZ2RiIG9uIHRoYXQgc3lzdGVtPzxicj4NCjxicj4NCkkgaGF2ZSB0cmll ZCB0byByZXByb2R1Y2Ugd2l0aCBhIGNvbmZpZyBzaW1pbGFyIHRvIHRoZSBvbmUgeW91IGRlc2Ny aWJlPGJyPg0KZGlkbid0IG1hbmFnZSB0byBwcm92b2tlIGEgc2VnZmF1bHQgd2l0aCByZTI0IG5v ciBtYXN0ZXIuPGJyPg0KPGJyPg0KT24gYSBzaWRlIG5vdGUsIEkgZG9uJ3QgdGhpbmsgcnVubmlu ZyB0aGUgY2hhaW4gb3ZlcmxheSB3aXRoIG1vZGU9c2VsZjxicj4NCndpbGwgd29yayB0byBwcm9w YWdhdGUgdGhlIHBwb2xpY3kgaW5mb3JtYXRpb24gdGhlIHdheSB5b3Ugd2FudC4gVGhlPGJyPg0K c2FtZSBmYWlsaW5nIGNyZWRlbnRpYWxzIHdpbGwgYmUgdXNlZCB0byBjb250YWN0IHRoZSB1cHN0 cmVhbSBzZXJ2ZXIgYW5kPGJyPg0Kc28gdGhlIGluaXRpYWwgYmluZCB3aWxsIGJlIHJlamVjdGVk IGFnYWluLCBub3QgYWxsb3dpbmcgdGhlPGJyPg0KbW9kaWZpY2F0aW9uIHRvIGJlIHBlcmZvcm1l ZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCi0tIDxicj4NCk9uZMWZZWogS3V6bsOt azxicj4NClNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcjxicj4NClN5bWFzIENvcnBvcmF0aW9uJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuc3ltYXMuY29tIj5odHRwOi8vd3d3 LnN5bWFzLmNvbTwvYT48YnI+DQpQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQgc3VwcG9ydGVkIExE QVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA8YnI+DQo8L2Rpdj4NCjwvc3Bhbj48L2Zv bnQ+PC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5cHg7IGxpbmUtaGVpZ2h0OiAxMHB4 OyI+VGhpcyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVn ZWQgb3IgY29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENhcGdlbWluaSBH cm91cC4gSXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIGl0IGlzIGFk ZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBu b3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwg ZGlzdHJpYnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5 b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLjwvc3Bh bj48L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR0202MB35530E1160E3DCDDFBD1D06ABA140AM0PR0202MB3553_--

1 0

(ITS#9029) MDB_MAP_FULL error after removing some records from DB
by adubovkin＠linkedin.com 28 May '19

28 May '19

Full_Name: Alex Version: LMDB 0.9.23 OS: iOS URL: https://hastebin.com/raw/arexecefew Submission from: (NULL) (2620:119:5001:3000:242c:3bea:acec:6a7d) Hey guys, We are using LMDB in our LRUCache implementation and facing the issue: when we evict old records from this cache sometimes we have MDB_MAP_FULL error though record eviction by using mdb_del() went fine. We were able to isolate an issue in the unit test which is run from just one thread. Since there are no any concurrent readers for this case we are expecting LMDB to claim free pages immediately after we commit "deletion" transaction, but in some rare cases it still raises MDB_MAP_FULL error. The unit test scenario is as follows: 1) start with empty DB 2) keep inserting random records until hi the first MDB_FULL 3) delete some old recrods to some pages 4) try to insert new record and check that is succeeded. The step 4 fails with another MDB_FULL error We enable debugging and attached a debug logs from LDMB. Hope it would be helpful.

1 0

Re: (ITS#9028) Not able to add 'syncprov' module
by quanah＠symas.com 27 May '19

27 May '19

--On Sunday, May 26, 2019 12:47 PM +0000 danybensighar(a)gmail.com wrote: > Full_Name: Dany Bensighar Hello, The ITS system is for bug reports. Usage questions such as this should be sent to the openldap-technical(a)openldap.org mailing list (<https://www.openldap.org/lists/mm/listinfo/openldap-technical>) This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9028) Not able to add 'syncprov' module
by danybensighar＠gmail.com 26 May '19

26 May '19

Full_Name: Dany Bensighar Version: 2.4.44 OS: Red Hat Enterprise Linux Server release 7.6 (Maipo) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.138.78.4) Hello, Iam setting up a master slave openldap configuration in rhel 7, while adding the syncprov module I am getting the below error. I have checked openspaces and special characters but nothing found Please find the syncprov.ldif file dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpSessionLog: 100 Please find the error ldapadd -Y EXTERNAL -H ldapi:/// -f syncprov.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=1001+uidNumber=1001,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry "olcOverlay=syncprov,olcDatabase={2}hdb,cn=config" ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax Your support will be highly appreciated

1 0

Re: (ITS#9027) LMDB: API to retrieve map address
by nic＠nicwatson.org 23 May '19

23 May '19

--000000000000856dab058992e756 Content-Type: text/plain; charset="UTF-8" The short answer is yes. Our mappings are now bigger than 1TiB (out of 2TiB total available). Also, it *seems* to be that it is just way faster for Linux to map things in order all at once. Additionally, we have some boxes that still have spinning disks, and sequential access is a couple orders of magnitude faster on those. I haven't looked at the logic in the Linux pager, but it seems to be fairly aggressive about taking memory pages back from large memory maps, even though it doesn't strictly need to. Locking the memory is a bit of a sledgehammer, but in our experience it is an effective one. On Thu, May 23, 2019 at 2:23 PM Howard Chu <hyc(a)symas.com> wrote: > github(a)nicwatson.org wrote: > > Full_Name: Nic Watson > > Version: > > OS: Linux > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (73.132.68.128) > > > > > > Goal: > > I'd like a clean way to get at the address of the data memory map in > LMDB. > > > > MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is used. > > > > Current Workarounds: > > * Use OS-specific mechanism to retrieve all memory maps (e.g. > > /proc/<pid>/smaps). > > * Defeat opaque handle and reach into the MDB_env struct directly and > grab the > > me_map field. > > > > Justification: > > In my current application, I notice a significant performance increase > if I > > mlock the mapfile. In order to do that cleanly, I need the address of > the map. > > That sounds odd. Is there a lot of memory pressure from other processes on > the machine? > Where is the performance loss or gain coming from? > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --000000000000856dab058992e756 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">The short answer is yes. Our mappings are now bigger than = 1TiB (out of 2TiB total available). Also, it *seems* to be that it is just = way faster for Linux to map things in order all at once. Additionally, we h= ave some boxes that still have spinning disks, and sequential access is a c= ouple orders of magnitude faster on those.<div><br></div><div>I haven't= looked at the logic in the Linux pager, but it seems to be fairly aggressi= ve about taking memory pages back from large memory maps, even though it do= esn't strictly need to. Locking the memory is a bit of a sledgehammer, = but in our experience it is an effective one.</div></div><br><div class=3D"= gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 23, 2019 at = 2:23 PM Howard Chu <<a href=3D"mailto:hyc@symas.com">hyc(a)symas.com</a>&g= t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a hre= f=3D"mailto:github@nicwatson.org" target=3D"_blank">github(a)nicwatson.org</a= > wrote:<br> > Full_Name: Nic Watson<br> > Version: <br> > OS: Linux<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" t= arget=3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> > Submission from: (NULL) (73.132.68.128)<br> > <br> > <br> > Goal:<br> > I'd like a clean way to get at the address of the data memory map = in LMDB.<br> > <br> > MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is us= ed.<br> > <br> > Current Workarounds:<br> > * Use OS-specific mechanism to retrieve all memory maps (e.g.<br> > /proc/<pid>/smaps). <br> > * Defeat opaque handle and reach into the MDB_env struct directly and = grab the<br> > me_map field.<br> > <br> > Justification:<br> > In my current application, I notice a significant performance increase= if I<br> > mlock the mapfile.=C2=A0 In order to do that cleanly, I need the addre= ss of the map.<br> <br> That sounds odd. Is there a lot of memory pressure from other processes on = the machine?<br> Where is the performance loss or gain coming from?<br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </blockquote></div> --000000000000856dab058992e756--

1 0

Re: (ITS#9027) LMDB: API to retrieve map address
by hyc＠symas.com 23 May '19

23 May '19

github(a)nicwatson.org wrote: > Full_Name: Nic Watson > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (73.132.68.128) > > > Goal: > I'd like a clean way to get at the address of the data memory map in LMDB. > > MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is used. > > Current Workarounds: > * Use OS-specific mechanism to retrieve all memory maps (e.g. > /proc/<pid>/smaps). > * Defeat opaque handle and reach into the MDB_env struct directly and grab the > me_map field. > > Justification: > In my current application, I notice a significant performance increase if I > mlock the mapfile. In order to do that cleanly, I need the address of the map. That sounds odd. Is there a lot of memory pressure from other processes on the machine? Where is the performance loss or gain coming from? -- -- 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

(ITS#9027) LMDB: API to retrieve map address
by github＠nicwatson.org 23 May '19

23 May '19

Full_Name: Nic Watson Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (73.132.68.128) Goal: I'd like a clean way to get at the address of the data memory map in LMDB. MDB_envinfo.me_mapaddr only returns the map address if MAP_FIXED is used. Current Workarounds: * Use OS-specific mechanism to retrieve all memory maps (e.g. /proc/<pid>/smaps). * Defeat opaque handle and reach into the MDB_env struct directly and grab the me_map field. Justification: In my current application, I notice a significant performance increase if I mlock the mapfile. In order to do that cleanly, I need the address of the map.

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 10:29:02AM +0000, AYANIDES, JEAN-PHILIPPE wrote: > Yes, it serves traffic. It doesn't crash until I run a bind with a > wrong password. > >> (gdb) cont >> Continuing. > > [LDAP search with wrong password] > >> [New Thread -1237541968 (LWP 29380)] > >> Program exited with code 0177. >> (gdb) thread apply all bt full > > Yes sorry, It runs on an old version of debian: 4:0 32 bits that I am > not authorised to upgrade. > > It the first time we record that sort of issue on that platform… Hi Jean-Philippe, are you able to reproduce this on a different system, if not, can you get a more recent gdb on that system? I have tried to reproduce with a config similar to the one you describe didn't manage to provoke a segfault with re24 nor master. On a side note, I don't think running the chain overlay with mode=self will work to propagate the ppolicy information the way you want. The same failing credentials will be used to contact the upstream server and so the initial bind will be rejected again, not allowing the modification to be performed. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_000_AM0PR0202MB35537CBC3DAD8A9A24C85FF4BA060AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 WWVzLCBpdCBzZXJ2ZXMgdHJhZmZpYy4gSXQgZG9lc24ndCBjcmFzaCB1bnRpbCBJIHJ1biBhIGJp bmQgd2l0aCBhIHdyb25nIHBhc3N3b3JkLg0KDQo+IChnZGIpIGNvbnQNCg0KPiBDb250aW51aW5n Lg0KDQoNCltMREFQIHNlYXJjaCB3aXRoIHdyb25nIHBhc3N3b3JkXQ0KDQoNCj4gW05ldyBUaHJl YWQgLTEyMzc1NDE5NjggKExXUCAyOTM4MCldDQoNCj4gUHJvZ3JhbSBleGl0ZWQgd2l0aCBjb2Rl IDAxNzcuDQo+IChnZGIpIHRocmVhZCBhcHBseSBhbGwgYnQgZnVsbA0KDQoNClllcyBzb3JyeSwg SXQgcnVucyBvbiBhbiBvbGQgdmVyc2lvbiBvZiBkZWJpYW46IDQ6MCAzMiBiaXRzIHRoYXQgSSBh bSBub3QgYXV0aG9yaXNlZCB0byB1cGdyYWRlLg0KDQpJdCB0aGUgZmlyc3QgdGltZSB3ZSByZWNv cmQgdGhhdCBzb3J0IG9mIGlzc3VlIG9uIHRoYXQgcGxhdGZvcm3igKYNCg0KDQpKZWFuLVBoaWxp cHBlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IE9uZMWZZWogS3V6 bsOtayA8b25kcmFAbWlzdG90ZWJlLm5ldD4NCkVudm95w6kgOiBsdW5kaSAyMCBtYWkgMjAxOSAx MjoyMDo0NQ0Kw4AgOiBBWUFOSURFUywgSkVBTi1QSElMSVBQRQ0KQ2MgOiBvcGVubGRhcC1pdHNA T3BlbkxEQVAub3JnDQpPYmpldCA6IFJlOiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5nIHBwb2xpY3kg Y2hhaW5pbmcgZnJvbSBzbGF2ZSB0byBtYXN0ZXINCg0KT24gTW9uLCBNYXkgMjAsIDIwMTkgYXQg MDk6NDQ6NDVBTSArMDAwMCwgQVlBTklERVMsIEpFQU4tUEhJTElQUEUgd3JvdGU6DQo+IEhlbGxv IE9uZMWZZWoNCj4NCj4gSSBoYXZlIHByb2NlZWRlZCBsaWtlIHRoaXMgYmVjYXVzZSBJIGhhZCBu b3RoaW5nIG1vcmUgdG8gc2hvdyENCg0KSGkgSmVhbi1QaGlsaXBwZSwNCmlzIHNsYXBkIGFjdHVh bGx5IHdpbGxpbmcgdG8gc2VydmUgYW55IHRyYWZmaWMgd2hpbGUgeW91IGxldCBnZGINCmNvbnRp bnVlIG9yIGRvZXMgaXQgc2F5IHNsYXBkIHN0b3BwZWQgaW1tZWRpYXRlbHk/DQoNCkFsc28sIHdo aWxlIHRoaXMgbWlnaHQgYmUgYSByZWQgaGVycmluZywgd2hhdCB2ZXJzaW9uIGFuZCBhcmNoaXRl Y3R1cmUNCm9mIERlYmlhbiBkbyB5b3UgdXNlPyBUaGVyZSBhcmUgc29tZSB0aGluZ3MgYWJvdXQg eW91ciBnZGIgb3V0cHV0IGFuZA0KbGlicmFyeSBsb2NhdGlvbnMgdGhhdCBJIGNhbid0IHJlY29u Y2lsZSB3aXRoIGFueSByZWNlbnQgRGViaWFuIHJlbGVhc2UuDQoNCj4gSWYgSSBydW4gdGhlIGNv bW1hbmRzIGFzIHlvdSBzYWlkOg0KPiAo4oCmKQ0KPg0KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2Fw cGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3Bwb2xpY3ktMi40LnNvLjINCj4g UmVhZGluZyBzeW1ib2xzIGZyb20gL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5s ZGFwL2JhY2tfbGRhcC0yLjQuc28uMi4uLmRvbmUuDQo+IExvYWRlZCBzeW1ib2xzIGZvciAvYXBw bGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3BlbmxkYXAvYmFja19sZGFwLTIuNC5zby4yDQo+ IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVu bGRhcC9wdy1zaGEyLnNvLjAuLi5kb25lLg0KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29w ZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3B3LXNoYTIuc28uMA0KPiBSZWFkaW5nIHN5 bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjIu Li5kb25lLg0KPiBMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIv bGlibGRhcF9yLTIuNC5zby4yDQo+IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRh cC0yLjQuNDcvbGliL2xpYmxiZXItMi40LnNvLjIuLi5kb25lLg0KPiBMb2FkZWQgc3ltYm9scyBm b3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGlibGJlci0yLjQuc28uMg0KPiBGYWlsZWQg dG8gcmVhZCBhIHZhbGlkIG9iamVjdCBmaWxlIGltYWdlIGZyb20gbWVtb3J5Lg0KPiAweGI3Yzkz MTgzIGluIHB0aHJlYWRfam9pbiAoKSBmcm9tIC9saWIvdGxzL2xpYnB0aHJlYWQuc28uMA0KPiAo Z2RiKSBzZXQgbG9nZ2luZyBvbg0KPiBDb3B5aW5nIG91dHB1dCB0byBnZGIudHh0Lg0KPiAoZ2Ri KSBjb250DQo+IENvbnRpbnVpbmcuDQo+IFtOZXcgVGhyZWFkIC0xMjM3NTQxOTY4IChMV1AgMjkz ODApXQ0KPg0KPiBQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny4NCj4gKGdkYikgdGhyZWFk IGFwcGx5IGFsbCBidCBmdWxsDQo+IChnZGIpDQo+IChnZGIpIHF1aXQNCg0KLS0NCk9uZMWZZWog S3V6bsOtaw0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVyDQpTeW1hcyBDb3Jwb3JhdGlvbiAgICAg ICAgICAgICAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NClBhY2thZ2VkLCBjZXJ0aWZp ZWQsIGFuZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUA0KVGhp cyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVnZWQgb3Ig Y29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENhcGdlbWluaSBHcm91cC4g SXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIGl0IGlzIGFkZHJlc3Nl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgYXV0 aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwgZGlzdHJp YnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5b3UgcmVj ZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLgo= --_000_AM0PR0202MB35537CBC3DAD8A9A24C85FF4BA060AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5ZZXMsIGl0IHNlcnZlcyB0cmFmZmljLiBJdCBk b2Vzbid0IGNyYXNoIHVudGlsIEkgcnVuIGEgYmluZCB3aXRoIGEgd3JvbmcgcGFzc3dvcmQuPC9w Pg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxmb250IHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgKGdkYikgY29udDxicj4NCjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxm b250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgQ29udGludWlu Zy48YnI+DQo8L3NwYW4+PC9mb250PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2lu LWJvdHRvbTowIj48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0i MiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+PGJyPg0KPC9zcGFuPjwvZm9udD48L3A+ DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0iMiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+W0xEQVAgc2VhcmNoIHdpdGggd3JvbmcgcGFz c3dvcmRdPGJyPg0KPC9zcGFuPjwvZm9udD48L3A+DQo8YnI+DQo8L3NwYW4+PC9mb250Pg0KPHA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxmb250IHNpemU9 IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPiZndDsgW05ldyBUaHJlYWQgLTEyMzc1 NDE5NjggKExXUCAyOTM4MCldPC9zcGFuPjwvZm9udD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRv cDowO21hcmdpbi1ib3R0b206MCI+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMXB0OyI+Jmd0OyBQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny48YnI+DQomZ3Q7IChn ZGIpIHRocmVhZCBhcHBseSBhbGwgYnQgZnVsbDwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5ZZXMgc29ycnksIEl0IHJ1bnMgb24gYW4gb2xkIHZl cnNpb24gb2YgZGViaWFuOiA0OjAgMzIgYml0cyB0aGF0IEkgYW0gbm90IGF1dGhvcmlzZWQgdG8g dXBncmFkZS48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+SXQg dGhlIGZpcnN0IHRpbWUgd2UgcmVjb3JkIHRoYXQgc29ydCBvZiBpc3N1ZSBvbiB0aGF0IHBsYXRm b3Jt4oCmPGJyPg0KPC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAi Pjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5KZWFu LVBoaWxpcHBlPGJyPg0KPC9wPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29sb3I6IzAwOThDQyI+PC9z cGFuPjwvc3Ryb25nPg0KPGRpdiBpZD0iU2lnbmF0dXJlIj48L2Rpdj4NCjwvZGl2Pg0KPGhyIHN0 eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2 IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1z ZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RGUgOjwvYj4g T25kxZllaiBLdXpuw61rICZsdDtvbmRyYUBtaXN0b3RlYmUubmV0Jmd0Ozxicj4NCjxiPkVudm95 w6kgOjwvYj4gbHVuZGkgMjAgbWFpIDIwMTkgMTI6MjA6NDU8YnI+DQo8Yj7DgCA6PC9iPiBBWUFO SURFUywgSkVBTi1QSElMSVBQRTxicj4NCjxiPkNjJm5ic3A7OjwvYj4gb3BlbmxkYXAtaXRzQE9w ZW5MREFQLm9yZzxicj4NCjxiPk9iamV0IDo8L2I+IFJlOiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5n IHBwb2xpY3kgY2hhaW5pbmcgZnJvbSBzbGF2ZSB0byBtYXN0ZXI8L2ZvbnQ+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5RnJhZ21lbnQiPjxmb250IHNpemU9IjIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPg0KPGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5P biBNb24sIE1heSAyMCwgMjAxOSBhdCAwOTo0NDo0NUFNICYjNDM7MDAwMCwgQVlBTklERVMsIEpF QU4tUEhJTElQUEUgd3JvdGU6PGJyPg0KJmd0OyBIZWxsbyBPbmTFmWVqPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEkgaGF2ZSBwcm9jZWVkZWQgbGlrZSB0aGlzIGJlY2F1c2UgSSBoYWQgbm90aGluZyBt b3JlIHRvIHNob3chPGJyPg0KPGJyPg0KSGkgSmVhbi1QaGlsaXBwZSw8YnI+DQppcyBzbGFwZCBh Y3R1YWxseSB3aWxsaW5nIHRvIHNlcnZlIGFueSB0cmFmZmljIHdoaWxlIHlvdSBsZXQgZ2RiPGJy Pg0KY29udGludWUgb3IgZG9lcyBpdCBzYXkgc2xhcGQgc3RvcHBlZCBpbW1lZGlhdGVseT88YnI+ DQo8YnI+DQpBbHNvLCB3aGlsZSB0aGlzIG1pZ2h0IGJlIGEgcmVkIGhlcnJpbmcsIHdoYXQgdmVy c2lvbiBhbmQgYXJjaGl0ZWN0dXJlPGJyPg0Kb2YgRGViaWFuIGRvIHlvdSB1c2U/IFRoZXJlIGFy ZSBzb21lIHRoaW5ncyBhYm91dCB5b3VyIGdkYiBvdXRwdXQgYW5kPGJyPg0KbGlicmFyeSBsb2Nh dGlvbnMgdGhhdCBJIGNhbid0IHJlY29uY2lsZSB3aXRoIGFueSByZWNlbnQgRGViaWFuIHJlbGVh c2UuPGJyPg0KPGJyPg0KJmd0OyBJZiBJIHJ1biB0aGUgY29tbWFuZHMgYXMgeW91IHNhaWQ6PGJy Pg0KJmd0OyAo4oCmKTxicj4NCiZndDsgPGJyPg0KJmd0OyBMb2FkZWQgc3ltYm9scyBmb3IgL2Fw cGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3Bwb2xpY3ktMi40LnNvLjI8YnI+ DQomZ3Q7IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhl Yy9vcGVubGRhcC9iYWNrX2xkYXAtMi40LnNvLjIuLi5kb25lLjxicj4NCiZndDsgTG9hZGVkIHN5 bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVubGRhcC9iYWNrX2xk YXAtMi40LnNvLjI8YnI+DQomZ3Q7IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVubGRh cC0yLjQuNDcvbGliZXhlYy9vcGVubGRhcC9wdy1zaGEyLnNvLjAuLi5kb25lLjxicj4NCiZndDsg TG9hZGVkIHN5bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVubGRh cC9wdy1zaGEyLnNvLjA8YnI+DQomZ3Q7IFJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9vcGVu bGRhcC0yLjQuNDcvbGliL2xpYmxkYXBfci0yLjQuc28uMi4uLmRvbmUuPGJyPg0KJmd0OyBMb2Fk ZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGlibGRhcF9yLTIuNC5z by4yPGJyPg0KJmd0OyBSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3 L2xpYi9saWJsYmVyLTIuNC5zby4yLi4uZG9uZS48YnI+DQomZ3Q7IExvYWRlZCBzeW1ib2xzIGZv ciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJsYmVyLTIuNC5zby4yPGJyPg0KJmd0OyBG YWlsZWQgdG8gcmVhZCBhIHZhbGlkIG9iamVjdCBmaWxlIGltYWdlIGZyb20gbWVtb3J5Ljxicj4N CiZndDsgMHhiN2M5MzE4MyBpbiBwdGhyZWFkX2pvaW4gKCkgZnJvbSAvbGliL3Rscy9saWJwdGhy ZWFkLnNvLjA8YnI+DQomZ3Q7IChnZGIpIHNldCBsb2dnaW5nIG9uPGJyPg0KJmd0OyBDb3B5aW5n IG91dHB1dCB0byBnZGIudHh0Ljxicj4NCiZndDsgKGdkYikgY29udDxicj4NCiZndDsgQ29udGlu dWluZy48YnI+DQomZ3Q7IFtOZXcgVGhyZWFkIC0xMjM3NTQxOTY4IChMV1AgMjkzODApXTxicj4N CiZndDsgPGJyPg0KJmd0OyBQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny48YnI+DQomZ3Q7 IChnZGIpIHRocmVhZCBhcHBseSBhbGwgYnQgZnVsbDxicj4NCiZndDsgKGdkYik8YnI+DQomZ3Q7 IChnZGIpIHF1aXQ8YnI+DQo8YnI+DQotLSA8YnI+DQpPbmTFmWVqIEt1em7DrWs8YnI+DQpTZW5p b3IgU29mdHdhcmUgRW5naW5lZXI8YnI+DQpTeW1hcyBDb3Jwb3JhdGlvbiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8YSBocmVmPSJodHRwOi8vd3d3LnN5bWFzLmNvbSI+aHR0cDovL3d3dy5zeW1hcy5jb208 L2E+PGJyPg0KUGFja2FnZWQsIGNlcnRpZmllZCwgYW5kIHN1cHBvcnRlZCBMREFQIHNvbHV0aW9u cyBwb3dlcmVkIGJ5IE9wZW5MREFQPGJyPg0KPC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOXB4OyBsaW5lLWhlaWdodDogMTBweDsiPlRoaXMgbWVz c2FnZSBjb250YWlucyBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZp ZGVudGlhbCBhbmQgaXMgdGhlIHByb3BlcnR5IG9mIHRoZSBDYXBnZW1pbmkgR3JvdXAuIEl0IGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gdG8gd2hvbSBpdCBpcyBhZGRyZXNzZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IGF1dGhvcml6 ZWQgdG8gcmVhZCwgcHJpbnQsIHJldGFpbiwgY29weSwgZGlzc2VtaW5hdGUsIGRpc3RyaWJ1dGUs IG9yIHVzZSB0aGlzIG1lc3NhZ2Ugb3IgYW55IHBhcnQgdGhlcmVvZi4gSWYgeW91IHJlY2VpdmUg dGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS48L3NwYW4+PC9ib2R5Pg0K PC9odG1sPg0K --_000_AM0PR0202MB35537CBC3DAD8A9A24C85FF4BA060AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 09:44:45AM +0000, AYANIDES, JEAN-PHILIPPE wrote: > Hello Ondřej > > I have proceeded like this because I had nothing more to show! Hi Jean-Philippe, is slapd actually willing to serve any traffic while you let gdb continue or does it say slapd stopped immediately? Also, while this might be a red herring, what version and architecture of Debian do you use? There are some things about your gdb output and library locations that I can't reconcile with any recent Debian release. > If I run the commands as you said: > (…) > > Loaded symbols for /appli/openldap-2.4.47/libexec/openldap/ppolicy-2.4.so.2 > Reading symbols from /appli/openldap-2.4.47/libexec/openldap/back_ldap-2.4.so.2...done. > Loaded symbols for /appli/openldap-2.4.47/libexec/openldap/back_ldap-2.4.so.2 > Reading symbols from /appli/openldap-2.4.47/libexec/openldap/pw-sha2.so.0...done. > Loaded symbols for /appli/openldap-2.4.47/libexec/openldap/pw-sha2.so.0 > Reading symbols from /appli/openldap-2.4.47/lib/libldap_r-2.4.so.2...done. > Loaded symbols for /appli/openldap-2.4.47/lib/libldap_r-2.4.so.2 > Reading symbols from /appli/openldap-2.4.47/lib/liblber-2.4.so.2...done. > Loaded symbols for /appli/openldap-2.4.47/lib/liblber-2.4.so.2 > Failed to read a valid object file image from memory. > 0xb7c93183 in pthread_join () from /lib/tls/libpthread.so.0 > (gdb) set logging on > Copying output to gdb.txt. > (gdb) cont > Continuing. > [New Thread -1237541968 (LWP 29380)] > > Program exited with code 0177. > (gdb) thread apply all bt full > (gdb) > (gdb) quit -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_000_AM0PR0202MB3553B6F7E1BAA0A82AF24A4FBA060AM0PR0202MB3553_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGVsbG8gT25kxZllag0KDQpJIGhhdmUgcHJvY2VlZGVkIGxpa2UgdGhpcyBiZWNhdXNlIEkgaGFk IG5vdGhpbmcgbW9yZSB0byBzaG93IQ0KDQpJZiBJIHJ1biB0aGUgY29tbWFuZHMgYXMgeW91IHNh aWQ6DQoNCg0KKOKApikNCg0KTG9hZGVkIHN5bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQu NDcvbGliZXhlYy9vcGVubGRhcC9wcG9saWN5LTIuNC5zby4yDQpSZWFkaW5nIHN5bWJvbHMgZnJv bSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3BlbmxkYXAvYmFja19sZGFwLTIuNC5z by4yLi4uZG9uZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xp YmV4ZWMvb3BlbmxkYXAvYmFja19sZGFwLTIuNC5zby4yDQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAv YXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3BlbmxkYXAvcHctc2hhMi5zby4wLi4uZG9u ZS4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3Bl bmxkYXAvcHctc2hhMi5zby4wDQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAt Mi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjIuLi5kb25lLg0KTG9hZGVkIHN5bWJvbHMgZm9y IC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliL2xpYmxkYXBfci0yLjQuc28uMg0KUmVhZGluZyBz eW1ib2xzIGZyb20gL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGlibGJlci0yLjQuc28uMi4u LmRvbmUuDQpMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5sZGFwLTIuNC40Ny9saWIvbGli bGJlci0yLjQuc28uMg0KRmFpbGVkIHRvIHJlYWQgYSB2YWxpZCBvYmplY3QgZmlsZSBpbWFnZSBm cm9tIG1lbW9yeS4NCjB4YjdjOTMxODMgaW4gcHRocmVhZF9qb2luICgpIGZyb20gL2xpYi90bHMv bGlicHRocmVhZC5zby4wDQooZ2RiKSBzZXQgbG9nZ2luZyBvbg0KQ29weWluZyBvdXRwdXQgdG8g Z2RiLnR4dC4NCihnZGIpIGNvbnQNCkNvbnRpbnVpbmcuDQpbTmV3IFRocmVhZCAtMTIzNzU0MTk2 OCAoTFdQIDI5MzgwKV0NCg0KUHJvZ3JhbSBleGl0ZWQgd2l0aCBjb2RlIDAxNzcuDQooZ2RiKSB0 aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCihnZGIpDQooZ2RiKSBxdWl0DQoNCg0KSSBnZXQgdGhl IGZpbGUgZ2RiLnR4dCBjb250YWluaW5nIG9ubHkgdGhhdDoNCg0KDQpyb290QHJhZGE6fiQgY2F0 IGdkYi50eHQNCkNvbnRpbnVpbmcuDQpbTmV3IFRocmVhZCAtMTIzNzQyNzI4MCAoTFdQIDMwODMp XQ0KDQpQcm9ncmFtIGV4aXRlZCB3aXRoIGNvZGUgMDE3Ny4NCnJvb3RAcmFkYTp+JA0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpEZSA6IE9uZMWZZWogS3V6bsOtayA8b25k cmFAbWlzdG90ZWJlLm5ldD4NCkVudm95w6kgOiBsdW5kaSAyMCBtYWkgMjAxOSAxMTozMDowMw0K w4AgOiBBWUFOSURFUywgSkVBTi1QSElMSVBQRQ0KQ2MgOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAu b3JnDQpPYmpldCA6IFJlOiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5nIHBwb2xpY3kgY2hhaW5pbmcg ZnJvbSBzbGF2ZSB0byBtYXN0ZXINCg0KT24gTW9uLCBNYXkgMjAsIDIwMTkgYXQgMDk6MTE6MjFB TSArMDAwMCwganBheWFuaWRlc0Bwcm9zb2RpZS5jb20gd3JvdGU6DQo+IEhlbGxvIFF1YW5haCwN Cj4NCj4gd2hhdCBJIGhhdmUgZG9uZToNCj4NCj4NCj4gL3Zhci9pbnN0YWxsL29wZW5sZGFwLTIu NC40Ny9zZXJ2ZXJzL3NsYXBkL3NsYXBkIC1oICJsZGFwOi8vKjozOTAgbGRhcHM6Ly8qPQ0KPiA6 NjM3IiAtbCBMT0NBTDUgLWYgL2FwcGxpL29wZW5sZGFwLXByZXByb2QvZXRjL3NsYXBkLmNvbmYg LXUgcm9vdCAtZyByb290IDs9DQo+ICBwcyBhdXggfCBncmVwIGxkYXANCj4NCj4gZ2RiIC92YXIv aW5zdGFsbC9vcGVubGRhcC0yLjQuNDcvc2VydmVycy9zbGFwZC9zbGFwZCAxNTY4NA0KPg0KPiAo Z2RiKSBzZXQgbG9nZ2luZyBvbg0KPiAoZ2RiKSB0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCj4g KGdkYikgY29udA0KPiA8Y3Jhc2hpbmcgb3BlcmF0aW9uPg0KPg0KPiBIZXJlIGlzIHRoZSBkdW1w Lg0KPg0KPiBTZWVtcyB0byBjcmFzaCB3aGVuIHJldHVybmluZyBmcm9tIGxpYnB0aHJlYWQNCg0K SGkgSmVhbi1QaGlsaXBwZSwNCnRoZSBiYWNrdHJhY2UgeW91IHJlY29yZGVkIHdhcyBkdXJpbmcg bm9ybWFsIG9wZXJhdGlvbiwgeW91IG5lZWQgdG8gZG8NCnRoZSBvcHBvc2l0ZSwgY29udGludWUg dG8gbGV0IHRoZSBwcm9ncmFtIGNyYXNoLCB3aXRoIGdkYiBpbnRlcmNlcHRpbmcNCnRoYXQuIFRo ZW4geW91IGNhbiB1c2UgJ3RocmVhZCBhcHBseSBhbGwgYnQgZnVsbCcgdG8gaW5zcGVjdCB0aGUg c3RhdGUNCm9mIHNsYXBkIGF0IHRoZSBwb2ludCBpdCBjcmFzaGVkLCBzbyB3aGF0IHNob3VsZCB5 b3UgZG86DQoNCj4gKGdkYikgY29udA0KPiA8Y3Jhc2hpbmcgb3BlcmF0aW9uPg0KPiAoZ2RiKSB0 aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwNCg0KUmVnYXJkcywNCg0KLS0NCk9uZMWZZWogS3V6bsOt aw0KU2VuaW9yIFNvZnR3YXJlIEVuZ2luZWVyDQpTeW1hcyBDb3Jwb3JhdGlvbiAgICAgICAgICAg ICAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NClBhY2thZ2VkLCBjZXJ0aWZpZWQsIGFu ZCBzdXBwb3J0ZWQgTERBUCBzb2x1dGlvbnMgcG93ZXJlZCBieSBPcGVuTERBUA0KVGhpcyBtZXNz YWdlIGNvbnRhaW5zIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsIGFuZCBpcyB0aGUgcHJvcGVydHkgb2YgdGhlIENhcGdlbWluaSBHcm91cC4gSXQgaXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgYXV0aG9yaXpl ZCB0byByZWFkLCBwcmludCwgcmV0YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwgZGlzdHJpYnV0ZSwg b3IgdXNlIHRoaXMgbWVzc2FnZSBvciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5b3UgcmVjZWl2ZSB0 aGlzIG1lc3NhZ2UgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVs eSBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLgo= --_000_AM0PR0202MB3553B6F7E1BAA0A82AF24A4FBA060AM0PR0202MB3553_ Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5IZWxsbyZuYnNwOzxmb250IHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPk9uZMWZZWombmJzcDs8L3NwYW4+PC9mb250Pjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5JIGhhdmUgcHJvY2Vl ZGVkIGxpa2UgdGhpcyBiZWNhdXNlIEkgaGFkIG5vdGhpbmcgbW9yZSB0byBzaG93ITwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5JZiBJIHJ1biB0aGUgY29tbWFu ZHMgYXMgeW91IHNhaWQ6PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9t OjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj4o 4oCmKTwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj48L3A+DQo8 ZGl2PkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMvb3Bl bmxkYXAvcHBvbGljeS0yLjQuc28uMjxicj4NClJlYWRpbmcgc3ltYm9scyBmcm9tIC9hcHBsaS9v cGVubGRhcC0yLjQuNDcvbGliZXhlYy9vcGVubGRhcC9iYWNrX2xkYXAtMi40LnNvLjIuLi5kb25l Ljxicj4NCkxvYWRlZCBzeW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYmV4ZWMv b3BlbmxkYXAvYmFja19sZGFwLTIuNC5zby4yPGJyPg0KUmVhZGluZyBzeW1ib2xzIGZyb20gL2Fw cGxpL29wZW5sZGFwLTIuNC40Ny9saWJleGVjL29wZW5sZGFwL3B3LXNoYTIuc28uMC4uLmRvbmUu PGJyPg0KTG9hZGVkIHN5bWJvbHMgZm9yIC9hcHBsaS9vcGVubGRhcC0yLjQuNDcvbGliZXhlYy9v cGVubGRhcC9wdy1zaGEyLnNvLjA8YnI+DQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3Bl bmxkYXAtMi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjIuLi5kb25lLjxicj4NCkxvYWRlZCBz eW1ib2xzIGZvciAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJsZGFwX3ItMi40LnNvLjI8 YnI+DQpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYXBwbGkvb3BlbmxkYXAtMi40LjQ3L2xpYi9saWJs YmVyLTIuNC5zby4yLi4uZG9uZS48YnI+DQpMb2FkZWQgc3ltYm9scyBmb3IgL2FwcGxpL29wZW5s ZGFwLTIuNC40Ny9saWIvbGlibGJlci0yLjQuc28uMjxicj4NCkZhaWxlZCB0byByZWFkIGEgdmFs aWQgb2JqZWN0IGZpbGUgaW1hZ2UgZnJvbSBtZW1vcnkuPGJyPg0KMHhiN2M5MzE4MyBpbiBwdGhy ZWFkX2pvaW4gKCkgZnJvbSAvbGliL3Rscy9saWJwdGhyZWFkLnNvLjA8YnI+DQooZ2RiKSBzZXQg bG9nZ2luZyBvbjxicj4NCkNvcHlpbmcgb3V0cHV0IHRvIGdkYi50eHQuPGJyPg0KKGdkYikgY29u dDxicj4NCkNvbnRpbnVpbmcuPGJyPg0KW05ldyBUaHJlYWQgLTEyMzc1NDE5NjggKExXUCAyOTM4 MCldPGJyPg0KPGJyPg0KUHJvZ3JhbSBleGl0ZWQgd2l0aCBjb2RlIDAxNzcuPGJyPg0KKGdkYikg dGhyZWFkIGFwcGx5IGFsbCBidCBmdWxsPGJyPg0KKGdkYik8YnI+DQooZ2RiKSBxdWl0PGJyPg0K PGJyPg0KPC9kaXY+DQo8cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0 b206MCI+SSBnZXQgdGhlIGZpbGUgZ2RiLnR4dCBjb250YWluaW5nIG9ubHkgdGhhdDo8L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MCI+PGJyPg0KPC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjwvcD4NCjxkaXY+cm9vdEByYWRhOn4k IGNhdCBnZGIudHh0PGJyPg0KQ29udGludWluZy48YnI+DQpbTmV3IFRocmVhZCAtMTIzNzQyNzI4 MCAoTFdQIDMwODMpXTxicj4NCjxicj4NClByb2dyYW0gZXhpdGVkIHdpdGggY29kZSAwMTc3Ljxi cj4NCnJvb3RAcmFkYTp+JDxicj4NCjxicj4NCjwvZGl2Pg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgY29s b3I6IzAwOThDQyI+PC9zcGFuPjwvc3Ryb25nPg0KPHA+PC9wPg0KPGRpdiBpZD0iU2lnbmF0dXJl Ij48L2Rpdj4NCjwvZGl2Pg0KPGhyIHN0eWxlPSJkaXNwbGF5OmlubGluZS1ibG9jazt3aWR0aDo5 OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIiBkaXI9Imx0ciI+PGZv bnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQtc2l6ZToxMXB0IiBjb2xv cj0iIzAwMDAwMCI+PGI+RGUgOjwvYj4gT25kxZllaiBLdXpuw61rICZsdDtvbmRyYUBtaXN0b3Rl YmUubmV0Jmd0Ozxicj4NCjxiPkVudm95w6kgOjwvYj4gbHVuZGkgMjAgbWFpIDIwMTkgMTE6MzA6 MDM8YnI+DQo8Yj7DgCA6PC9iPiBBWUFOSURFUywgSkVBTi1QSElMSVBQRTxicj4NCjxiPkNjJm5i c3A7OjwvYj4gb3BlbmxkYXAtaXRzQE9wZW5MREFQLm9yZzxicj4NCjxiPk9iamV0IDo8L2I+IFJl OiAoSVRTIzkwMjMpIGNyYXNoIHVzaW5nIHBwb2xpY3kgY2hhaW5pbmcgZnJvbSBzbGF2ZSB0byBt YXN0ZXI8L2ZvbnQ+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJCb2R5 RnJhZ21lbnQiPjxmb250IHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPg0K PGRpdiBjbGFzcz0iUGxhaW5UZXh0Ij5PbiBNb24sIE1heSAyMCwgMjAxOSBhdCAwOToxMToyMUFN ICYjNDM7MDAwMCwganBheWFuaWRlc0Bwcm9zb2RpZS5jb20gd3JvdGU6PGJyPg0KJmd0OyBIZWxs byBRdWFuYWgsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHdoYXQgSSBoYXZlIGRvbmU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgL3Zhci9pbnN0YWxsL29wZW5sZGFwLTIuNC40Ny9zZXJ2 ZXJzL3NsYXBkL3NsYXBkIC1oICZxdW90O2xkYXA6Ly8qOjM5MCBsZGFwczovLyo9PGJyPg0KJmd0 OyA6NjM3JnF1b3Q7IC1sIExPQ0FMNSAtZiAvYXBwbGkvb3BlbmxkYXAtcHJlcHJvZC9ldGMvc2xh cGQuY29uZiAtdSByb290IC1nIHJvb3QgOz08YnI+DQomZ3Q7Jm5ic3A7IHBzIGF1eCB8IGdyZXAg bGRhcDxicj4NCiZndDsgPGJyPg0KJmd0OyBnZGIgL3Zhci9pbnN0YWxsL29wZW5sZGFwLTIuNC40 Ny9zZXJ2ZXJzL3NsYXBkL3NsYXBkIDE1Njg0PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IChnZGIpIHNl dCBsb2dnaW5nIG9uPGJyPg0KJmd0OyAoZ2RiKSB0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGw8YnI+ DQomZ3Q7IChnZGIpIGNvbnQ8YnI+DQomZ3Q7ICZsdDtjcmFzaGluZyBvcGVyYXRpb24mZ3Q7PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEhlcmUgaXMgdGhlIGR1bXAuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFNlZW1zIHRvIGNyYXNoIHdoZW4gcmV0dXJuaW5nIGZyb20gbGlicHRocmVhZDxicj4NCjxicj4N CkhpIEplYW4tUGhpbGlwcGUsPGJyPg0KdGhlIGJhY2t0cmFjZSB5b3UgcmVjb3JkZWQgd2FzIGR1 cmluZyBub3JtYWwgb3BlcmF0aW9uLCB5b3UgbmVlZCB0byBkbzxicj4NCnRoZSBvcHBvc2l0ZSwg Y29udGludWUgdG8gbGV0IHRoZSBwcm9ncmFtIGNyYXNoLCB3aXRoIGdkYiBpbnRlcmNlcHRpbmc8 YnI+DQp0aGF0LiBUaGVuIHlvdSBjYW4gdXNlICd0aHJlYWQgYXBwbHkgYWxsIGJ0IGZ1bGwnIHRv IGluc3BlY3QgdGhlIHN0YXRlPGJyPg0Kb2Ygc2xhcGQgYXQgdGhlIHBvaW50IGl0IGNyYXNoZWQs IHNvIHdoYXQgc2hvdWxkIHlvdSBkbzo8YnI+DQo8YnI+DQomZ3Q7IChnZGIpIGNvbnQ8YnI+DQom Z3Q7ICZsdDtjcmFzaGluZyBvcGVyYXRpb24mZ3Q7PGJyPg0KJmd0OyAoZ2RiKSB0aHJlYWQgYXBw bHkgYWxsIGJ0IGZ1bGw8YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCi0tIDxicj4NCk9u ZMWZZWogS3V6bsOtazxicj4NClNlbmlvciBTb2Z0d2FyZSBFbmdpbmVlcjxicj4NClN5bWFzIENv cnBvcmF0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly93d3cuc3ltYXMuY29t Ij5odHRwOi8vd3d3LnN5bWFzLmNvbTwvYT48YnI+DQpQYWNrYWdlZCwgY2VydGlmaWVkLCBhbmQg c3VwcG9ydGVkIExEQVAgc29sdXRpb25zIHBvd2VyZWQgYnkgT3BlbkxEQVA8YnI+DQo8L2Rpdj4N Cjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8cD48L3A+DQoNCjxwPjwvcD4NCg0KPHA+PC9wPg0KDQo8 cCBzdHlsZT0iZm9udC1zaXplOiA5cHg7ICI+VGhpcyBtZXNzYWdlIGNvbnRhaW5zIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsIGFuZCBpcyB0aGUgcHJv cGVydHkgb2YgdGhlIENhcGdlbWluaSBHcm91cC4gSXQgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhl IHBlcnNvbiB0byB3aG9tIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBub3QgYXV0aG9yaXplZCB0byByZWFkLCBwcmludCwgcmV0 YWluLCBjb3B5LCBkaXNzZW1pbmF0ZSwgZGlzdHJpYnV0ZSwgb3IgdXNlIHRoaXMgbWVzc2FnZSBv ciBhbnkgcGFydCB0aGVyZW9mLiBJZiB5b3UgcmVjZWl2ZSB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIGFsbCBjb3Bp ZXMgb2YgdGhpcyBtZXNzYWdlLjwvcD48L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR0202MB3553B6F7E1BAA0A82AF24A4FBA060AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by ondra＠mistotebe.net 20 May '19

20 May '19

On Mon, May 20, 2019 at 09:11:21AM +0000, jpayanides(a)prosodie.com wrote: > Hello Quanah, > > what I have done: > > > /var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390 ldaps://*= > :637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u root -g root ;= > ps aux | grep ldap > > gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684 > > (gdb) set logging on > (gdb) thread apply all bt full > (gdb) cont > <crashing operation> > > Here is the dump. > > Seems to crash when returning from libpthread Hi Jean-Philippe, the backtrace you recorded was during normal operation, you need to do the opposite, continue to let the program crash, with gdb intercepting that. Then you can use 'thread apply all bt full' to inspect the state of slapd at the point it crashed, so what should you do: > (gdb) cont > <crashing operation> > (gdb) thread apply all bt full Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 20 May '19

20 May '19

--_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: multipart/alternative; boundary="_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_" --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, what I have done: /var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390 ldaps://*= :637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u root -g root ;= ps aux | grep ldap gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684 (gdb) set logging on (gdb) thread apply all bt full (gdb) cont <crashing operation> Here is the dump. Seems to crash when returning from libpthread -- Jean-Philippe ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 17:30:42 =C0 : AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org Objet : RE: (ITS#9023) crash using ppolicy chaining from slave to master --On Friday, May 17, 2019 4:09 PM +0000 "AYANIDES, JEAN-PHILIPPE" <jpayanides(a)prosodie.com> wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> This message contains information that may be privileged or confidential an= d is the property of the Capgemini Group. It is intended only for the perso= n to whom it is addressed. If you are not the intended recipient, you are n= ot authorized to read, print, retain, copy, disseminate, distribute, or use= this message or any part thereof. If you receive this message in error, pl= ease notify the sender immediately and delete all copies of this message. --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Quanah,</p> <p style=3D"margin-top:0;margin-bottom:0">what I have done:</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0"></p> <div>/var/install/openldap-2.4.47/servers/slapd/slapd -h "ldap://*:390= ldaps://*:637" -l LOCAL5 -f /appli/openldap-preprod/etc/slapd.conf -u= root -g root ; ps aux | grep ldap<br> </div> <div> <div><br> </div> <div>gdb /var/install/openldap-2.4.47/servers/slapd/slapd 15684<br> <br> </div> (gdb) set logging on</div> <div>(gdb) thread apply all bt full</div> <div>(gdb) cont</div> <div><crashing operation><br> </div> <br> <p></p> <p style=3D"margin-top:0;margin-bottom:0">Here is the dump.</p> <p style=3D"margin-top:0;margin-bottom:0"><br> </p> <p style=3D"margin-top:0;margin-bottom:0">Seems to crash when returning fro= m libpthread<br> </p> <p style=3D"margin-top:0;margin-bottom:0">--</p> <p style=3D"margin-top:0;margin-bottom:0">Jean-Philippe<br> </p> <div id=3D"Signature"> <meta content=3D"text/html; charset=3DUTF-8"> </div> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Quanah Gibson-Mount &l= t;quanah(a)symas.com><br> <b>Envoy=E9 :</b> vendredi 17 mai 2019 17:30:42<br> <b>=C0 :</b> AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org<br> <b>Objet :</b> RE: (ITS#9023) crash using ppolicy chaining from slave to ma= ster</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">--On Friday, May 17, 2019 4:09 PM +0000 "= AYANIDES, JEAN-PHILIPPE" <br> <jpayanides(a)prosodie.com> wrote:<br> <br> ><br> ><br> > Hello Quanah,<br> ><br> > I am not very familiar with gdb. Can you help me doing that?<br> <br> <br> Start slapd on the server that's crashing<br> Get the process ID of slapd<br> <br> gdb /path/to/slapd PID<br> <br> For example, if slapd is located in /usr/sbin, and the process ID is 1234:<= br> <br> gdb /usr/sbin/slapd 1234<br> <br> At the (gdb) prompt, enter the command "cont" to continue executi= on<br> <br> Run your operation that causes slapd to crash.  This should drop you b= ack <br> to the (gdb) prompt.<br> <br> Then run the command:<br> <br> thr apply all bt full<br> <br> This will provide the full backtrace.<br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com">http://www.symas.com</a>><br> <br> </div> </span></font></div> <span style=3D"font-size: 9px; line-height: 10px;">This message contains in= formation that may be privileged or confidential and is the property of the= Capgemini Group. It is intended only for the person to whom it is addresse= d. If you are not the intended recipient, you are not authorized to read, p= rint, retain, copy, disseminate, distribute, or use this message or any par= t thereof. If you receive this message in error, please notify the sender i= mmediately and delete all copies of this message.</span></body> </html> --_000_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_-- --_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_ Content-Type: text/plain; name="gdb.txt" Content-Description: gdb.txt Content-Disposition: attachment; filename="gdb.txt"; size=2695; creation-date="Mon, 20 May 2019 09:10:06 GMT"; modification-date="Mon, 20 May 2019 09:10:06 GMT" Content-Transfer-Encoding: base64 ClRocmVhZCAzIChUaHJlYWQgLTEyMjc2OTkyODAgKExXUCAxNTY4NykpOgojMCAgMHhiN2M4ODY3 OSBpbiBlcG9sbF93YWl0ICgpIGZyb20gL2xpYi90bHMvbGliYy5zby42Ck5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzEgIDB4MDgwNzljYmQgaW4gc2xhcGRfZGFlbW9uX3Rhc2sgKHB0 cj0weDApIGF0IGRhZW1vbi5jOjI1MzkKICAgICAgICBhY3RpdmUgPSAwCiAgICAgICAgbCA9IDx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PgogICAgICAgIGxhc3RfaWRsZV9jaGVjayA9IDE1NTgzNDMwMzgK ICAgICAgICBlYmFkZiA9IDAKIzIgIDB4YjdjZjQwYmQgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20g L2xpYi90bHMvbGlicHRocmVhZC5zby4wCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzMgIDB4YjdjODgwMWUgaW4gY2xvbmUgKCkgZnJvbSAvbGliL3Rscy9saWJjLnNvLjYKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoKVGhyZWFkIDIgKFRocmVhZCAtMTIzMTg5MzU4NCAo TFdQIDE1Njg4KSk6CiMwICAweGI3Y2Y2YzAxIGluIHB0aHJlYWRfY29uZF93YWl0QEBHTElCQ18y LjMuMiAoKSBmcm9tIC9saWIvdGxzL2xpYnB0aHJlYWQuc28uMApObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMxICAweDA4MTc4ZGNmIGluIGxkYXBfaW50X3RocmVhZF9wb29sX3dyYXBw ZXIgKHhwb29sPTB4ODJhOWMzMCkgYXQgdHBvb2wuYzo2ODMKICAgICAgICB0YXNrID0gKGxkYXBf aW50X3RocmVhZF90YXNrX3QgKikgMHgwCiAgICAgICAgd29ya19saXN0ID0gKGxkYXBfaW50X3Rw b29sX3BsaXN0X3QgKikgMHgxCiAgICAgICAgY3R4ID0ge2x0dV9pZCA9IDMwNjMwNzM3MTIsIGx0 dV9rZXkgPSB7e2x0a19rZXkgPSAweDgwZDM3ZjAsIGx0a19kYXRhID0gMHg4MzViNGQwLAogICAg ICBsdGtfZnJlZSA9IDB4ODBkMzgyMCA8c2xhcF9zbF9tZW1fZGVzdHJveT59LCB7bHRrX2tleSA9 IDB4ODMzZmE4OCwgbHRrX2RhdGEgPSAweDgzNjZkNTAsCiAgICAgIGx0a19mcmVlID0gMHg4MTMz OGQwIDxiZGJfcmVhZGVyX2ZyZWU+fSwge2x0a19rZXkgPSAweDAsIGx0a19kYXRhID0gMHgwLAog ICAgICBsdGtfZnJlZSA9IDB9IDxyZXBlYXRzIDMwIHRpbWVzPn19CiAgICAgICAga2N0eCA9IDx2 YWx1ZSBvcHRpbWl6ZWQgb3V0PgogICAgICAgIGtleXNsb3QgPSAxMzEKICAgICAgICBoYXNoID0g PHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgX19QUkVUVFlfRlVOQ1RJT05fXyA9ICJsZGFw X2ludF90aHJlYWRfcG9vbF93cmFwcGVyIgojMiAgMHhiN2NmNDBiZCBpbiBzdGFydF90aHJlYWQg KCkgZnJvbSAvbGliL3Rscy9saWJwdGhyZWFkLnNvLjAKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMyAgMHhiN2M4ODAxZSBpbiBjbG9uZSAoKSBmcm9tIC9saWIvdGxzL2xpYmMuc28u NgpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCgpUaHJlYWQgMSAoVGhyZWFkIC0xMjEy NTE2MTI4IChMV1AgMTU2ODQpKToKIzAgIDB4YjdjZjUxODMgaW4gcHRocmVhZF9qb2luICgpIGZy b20gL2xpYi90bHMvbGlicHRocmVhZC5zby4wCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzEgIDB4MDgwNzZmMWEgaW4gc2xhcGRfZGFlbW9uICgpIGF0IGRhZW1vbi5jOjI5MzIKICAg ICAgICBpID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgcmMgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4KIzIgIDB4MDgwNjI5NTcgaW4gbWFpbiAoYXJnYz0xMSwgYXJndj0weGJmODA3NDI0 KSBhdCBtYWluLmM6MTAxNwogICAgICAgIGkgPSAxMQogICAgICAgIG5vX2RldGFjaCA9IDAKICAg ICAgICByYyA9IDAKICAgICAgICB1cmxzID0gMHg4MjgwMDA4ICJsZGFwOi8vKjozOTAgbGRhcHM6 Ly8qOjYzNyIKICAgICAgICB1c2VybmFtZSA9IDB4ODI4MDA1OCAicm9vdCIKICAgICAgICBncm91 cG5hbWUgPSAweDgyODAwNjggImxkYXAiCiAgICAgICAgc2FuZGJveCA9IDB4MAogICAgICAgIHN5 c2xvZ1VzZXIgPSAxNjgKICAgICAgICBwaWQgPSA8dmFsdWUgb3B0aW1pemVkIG91dD4KICAgICAg ICB3YWl0ZmRzID0gezExLCAxMn0KICAgICAgICBjb25maWdmaWxlID0gMHg4MjgwMDI4ICIvYXBw bGkvb3BlbmxkYXAtcHJlcHJvZC9ldGMvc2xhcGQuY29uZiIKICAgICAgICBjb25maWdkaXIgPSAw eDAKICAgICAgICBzZXJ2ZXJOYW1lID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2Nw ID0gPHZhbHVlIG9wdGltaXplZCBvdXQ+CiAgICAgICAgc2NwX2VudHJ5ID0gPHZhbHVlIG9wdGlt aXplZCBvdXQ+CiAgICAgICAgZGVidWdfdW5rbm93bnMgPSAoY2hhciAqKikgMHgwCiAgICAgICAg c3lzbG9nX3Vua25vd25zID0gKGNoYXIgKiopIDB4MAogICAgICAgIGwgPSA8dmFsdWUgb3B0aW1p emVkIG91dD4KICAgICAgICBzbGFwZF9waWRfZmlsZV91bmxpbmsgPSAxCiAgICAgICAgc2xhcGRf YXJnc19maWxlX3VubGluayA9IDEKICAgICAgICBmaXJzdG9wdCA9IDx2YWx1ZSBvcHRpbWl6ZWQg b3V0PgogICAgICAgIF9fUFJFVFRZX0ZVTkNUSU9OX18gPSAibWFpbiIKIzAgIDB4YjdjZjUxODMg aW4gcHRocmVhZF9qb2luICgpIGZyb20gL2xpYi90bHMvbGlicHRocmVhZC5zby4wCkNvbnRpbnVp bmcuCltOZXcgVGhyZWFkIC0xMjM3MTQwNTYwIChMV1AgMTY4NzYpXQoKUHJvZ3JhbSBleGl0ZWQg d2l0aCBjb2RlIDAxNzcuCg== --_004_AM0PR0202MB355397966458DFBCF87CDE19BA060AM0PR0202MB3553_--

1 0

Re: (ITS#9026) slapd
by ryan＠nardis.ca 20 May '19

20 May '19

Hello, On Mon, May 20, 2019 at 03:38:49AM +0000, vkelkar(a)ucsd.edu wrote: >Version: 2.4.47 >OS: ubuntu This ITS tracks issues about OpenLDAP software itself. It sounds like your issue relates to the Ubuntu slapd package. In that case it should be reported in the Ubuntu tracker (Launchpad), or to Canonical support. In any case, your message did not really include enough information to diagnose your issue. When you report the issue elsewhere, please include the complete terminal output from the apt-get or dpkg command you ran, and the exact version of the slapd package (can be obtained from e.g. 'dpkg-query -W slapd'). I will close this ITS for now. It can be reopened if the issue actually turns out to be a problem with OpenLDAP software. Thanks Ryan

1 0

(ITS#9026) slapd
by vkelkar＠ucsd.edu 20 May '19

20 May '19

Full_Name: Vikram Kelkar Version: 2.4.47 OS: ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.110.67.70) We are having issues uninstalling slapd. We did apt-get install slapd and are trying to remove the package but for some reason it cannot. We tried remove, purge, and even went to the dpkg and removed slapd from there. The issue is we are running an iRedMail script and it will not let us run it because it says Error processing package slapd, exit status(1).

1 0

Re: (ITS#9025) Suggested enhancement: Automatically order module loading according to dependencies
by quanah＠symas.com 18 May '19

18 May '19

--On Saturday, May 18, 2019 9:48 AM +0000 james(a)turnersoft.co.uk wrote: > Full_Name: James Turner > Version: 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.86.27.193) > > > As OpenLDAP 2.4, system administrators have to make sure that they > configure the correct order in which modules are loaded during sever > startup. (e.g. load "back_monitor" last, "auditlog" typically second from > last). Configuring this order incorrectly often prevents the server from > starting up, or modules from functioning as expected. I've never encountered a situation where the order in which moduleload executes matters. Can you please provide an example configuration exhibiting problematic behavior based on moduleload order? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9025) Suggested enhancement: Automatically order module loading according to dependencies
by james＠turnersoft.co.uk 18 May '19

18 May '19

Full_Name: James Turner Version: 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.86.27.193) As OpenLDAP 2.4, system administrators have to make sure that they configure the correct order in which modules are loaded during sever startup. (e.g. load "back_monitor" last, "auditlog" typically second from last). Configuring this order incorrectly often prevents the server from starting up, or modules from functioning as expected. Is it feasible for a future version of OpenLDAP to determine the correct module loading order automatically (e.g. using dependency metadata for each module) so that everything "just works" without the sysadmin having to figure it out by hand? Step 1: Parse all the olcModuleList objects under cn=config to obtain a complete set of {path,module name} tuples. Step 2: Topologically sort the list based on known dependencies between the modules. Step 3: Load the modules in the correctly sorted order. In terms of design, this arguably strengthens the conceptual model that the objects under cn=config declare the OpenLDAP configuration which can be modified as the system runs, rather than an imperative sequence of actions to carry out at startup.

1 0

Re: (ITS#8060) mdb_from_db (bdb import)
by quanah＠symas.com 17 May '19

17 May '19

--On Tuesday, February 17, 2015 5:07 PM +0000 graehl(a)gmail.com wrote: > Full_Name: Jonathan Graehl > Version: n/a > OS: n/a > URL: > ftp://ftp.openldap.org/incoming/0001-mdb_from_db-new-options-bugfix.patch > Submission from: (NULL) (104.174.227.200) > > > (see 0001-mdb_from_db-new-options-bugfix.patch) > > mdb_from_db utility for direct import from Berkeley DB to mdb > > Apparently this can only be distributed in binary form using older > berkeley db versions, but building the utility from source for bulk > import should be fine. Hello, This submission is missing a required IPR, as noted at <https://www.openldap.org/devel/contributing.html#notice> An IPR is necessary to consider this work. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 5:30 PM +0000 khng300(a)gmail.com wrote: > Bump. I've added this to the review list. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 17 May '19

17 May '19

Bump. Ka Ho

1 0

Re: (ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 5:02 PM +0000 khng300(a)gmail.com wrote: > Full_Name: Ka Ho Ng > Version: mdb.master > OS: FreeBSD 12.0-RELEASE > URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch > Submission from: (NULL) (2001:470:fa95:1300::3) > > By the way, please help close ITS#8986 as this version is a resend of the > patch. The correct path is to follow up to your original ITS, not submit a new one. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9024) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 17 May '19

17 May '19

Full_Name: Ka Ho Ng Version: mdb.master OS: FreeBSD 12.0-RELEASE URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190517.patch Submission from: (NULL) (2001:470:fa95:1300::3) Starting from __FreeBSD_version 1200059 union semun definition was removed from userspace headers in order to comply with POSIX. In order to resurrect the defintion we need to define _WANT_SEMUN before including sys/sem.h for __FreeBSD_version >= 1200059. I tried to touch as small amount of code as possible here to avoid interfering with other platforms I do not use. By the way, please help close ITS#8986 as this version is a resend of the patch.

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 4:09 PM +0000 "AYANIDES, JEAN-PHILIPPE" <jpayanides(a)prosodie.com> wrote: > > > Hello Quanah, > > I am not very familiar with gdb. Can you help me doing that? Start slapd on the server that's crashing Get the process ID of slapd gdb /path/to/slapd PID For example, if slapd is located in /usr/sbin, and the process ID is 1234: gdb /usr/sbin/slapd 1234 At the (gdb) prompt, enter the command "cont" to continue execution Run your operation that causes slapd to crash. This should drop you back to the (gdb) prompt. Then run the command: thr apply all bt full This will provide the full backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#9023) crash using ppolicy chaining from slave to master
by jpayanides＠prosodie.com 17 May '19

17 May '19

--_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hello Quanah, I am not very familiar with gdb. Can you help me doing that? ________________________________ De : Quanah Gibson-Mount <quanah(a)symas.com> Envoy=E9 : vendredi 17 mai 2019 16:58:59 =C0 : AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org Objet : Re: (ITS#9023) crash using ppolicy chaining from slave to master --On Friday, May 17, 2019 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> This message contains information that may be privileged or confidential an= d is the property of the Capgemini Group. It is intended only for the perso= n to whom it is addressed. If you are not the intended recipient, you are n= ot authorized to read, print, retain, copy, disseminate, distribute, or use= this message or any part thereof. If you receive this message in error, pl= ease notify the sender immediately and delete all copies of this message. --_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_ Content-Type: text/html; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" style=3D"display:none;"></style> </head> <body dir=3D"ltr"> <div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font= -family:Calibri,Helvetica,sans-serif;" dir=3D"ltr"> <p style=3D"margin-top:0;margin-bottom:0">Hello Quanah,</p> <p style=3D"margin-top:0;margin-bottom:0">I am not very familiar with gdb. = Can you help me doing that?<br> </p> <strong><span style=3D"font-family:"Arial","sans-serif"= ; color:#0098CC"></span></strong> <div id=3D"Signature"></div> </div> <hr style=3D"display:inline-block;width:98%" tabindex=3D"-1"> <div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st= yle=3D"font-size:11pt" color=3D"#000000"><b>De :</b> Quanah Gibson-Mount &l= t;quanah(a)symas.com><br> <b>Envoy=E9 :</b> vendredi 17 mai 2019 16:58:59<br> <b>=C0 :</b> AYANIDES, JEAN-PHILIPPE; openldap-its(a)OpenLDAP.org<br> <b>Objet :</b> Re: (ITS#9023) crash using ppolicy chaining from slave to ma= ster</font> <div> </div> </div> <div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;= "> <div class=3D"PlainText">--On Friday, May 17, 2019 3:50 PM +0000 jpayan= ides(a)prosodie.com wrote:<br> <br> > Full_Name: JPh Ayanides<br> > Version: 2.4.47<br> > OS: Linux Debian<br> > URL: <a href=3D"ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.o= rg/incoming/</a><br> > Submission from: (NULL) (195.46.216.78)<br> ><br> ><br> > Hello, I cannot succeed in making the following configuration to work.= <br> > Instead of that, openldap crashes.<br> ><br> > I have 2 openldap servers in master-slave: the slave is installed on a= <br> > machine named rada, and a master is installed on another machine named= <br> > simby. The ppolicy is activated on rada and simby, and I use chain and= <br> > updateref in order to sync failures in ppolicy coming from rada back t= o<br> > simby. When I test that feature, with trying a bind with a wrong<br> > password,  openldap on the slave crashes. I failed in understandi= ng why,<br> > even with gdb.<br> <br> Ensure you have debugging symbols installed, and provide a full backtrace <= br> of all threads from gdb.<br> <br> --Quanah<br> <br> <br> --<br> <br> Quanah Gibson-Mount<br> Product Architect<br> Symas Corporation<br> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:<br> <<a href=3D"http://www.symas.com">http://www.symas.com</a>><br> <br> </div> </span></font></div> <span style=3D"font-size: 9px; line-height: 10px;">This message contains in= formation that may be privileged or confidential and is the property of the= Capgemini Group. It is intended only for the person to whom it is addresse= d. If you are not the intended recipient, you are not authorized to read, p= rint, retain, copy, disseminate, distribute, or use this message or any par= t thereof. If you receive this message in error, please notify the sender i= mmediately and delete all copies of this message.</span></body> </html> --_000_AM0PR0202MB355359CC89C5DBD53D8FAB09BA0B0AM0PR0202MB3553_--

1 0

Re: (ITS#9023) crash using ppolicy chaining from slave to master
by quanah＠symas.com 17 May '19

17 May '19

--On Friday, May 17, 2019 3:50 PM +0000 jpayanides(a)prosodie.com wrote: > Full_Name: JPh Ayanides > Version: 2.4.47 > OS: Linux Debian > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.46.216.78) > > > Hello, I cannot succeed in making the following configuration to work. > Instead of that, openldap crashes. > > I have 2 openldap servers in master-slave: the slave is installed on a > machine named rada, and a master is installed on another machine named > simby. The ppolicy is activated on rada and simby, and I use chain and > updateref in order to sync failures in ppolicy coming from rada back to > simby. When I test that feature, with trying a bind with a wrong > password, openldap on the slave crashes. I failed in understanding why, > even with gdb. Ensure you have debugging symbols installed, and provide a full backtrace of all threads from gdb. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs