openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

[Issue 8950] segfault with TXN+accesslog
by openldap-its＠openldap.org 23 Mar '21

23 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8950 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c6e521fa by Howard Chu at 2021-03-23T14:58:09+00:00 ITS#8950 move txn setup to frontend -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8668] pcache failing to update after entry moved
by openldap-its＠openldap.org 23 Mar '21

23 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8668 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.3 |--- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8668] pcache failing to update after entry moved
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8668 --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- (In reply to Howard Chu from comment #3) > I was able to reproduce the behavior, but there is no bug here. > > You're seeing the old entry because it's left over from a previous run of > slapd. > The pcache overlay will forget what it knows about the cache contents on a > restart, unless you configure pcachePersist. When you enable this setting, > then it remembers its cached queries across restarts and will expire old > entries instead of returning them in new search requests. To be clear: I could only reproduce this behavior if slapd was stopped and restarted between queries: 1: perform a cacheable search 2: shutdown slapd and restart before cached query expires 3: move entry on remote server 4: repeat the cacheable search 5: repeat the cacheable search again On step 1, pcache will query the remote and store a copy of the returned entry. On step 2, the restart will make pcache forget it stored anything. On step 4, pcache will query the remote server because it thinks its cache is empty, and store and return the new result (only). On step 5, pcache will serve the request entirely from cache, and return both the old and new entries. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8668] pcache failing to update after entry moved
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=8668 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- I was able to reproduce the behavior, but there is no bug here. You're seeing the old entry because it's left over from a previous run of slapd. The pcache overlay will forget what it knows about the cache contents on a restart, unless you configure pcachePersist. When you enable this setting, then it remembers its cached queries across restarts and will expire old entries instead of returning them in new search requests. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9251] slapd tries to allocate huge amounts of memory for deeply nested filter
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9251 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ, reviewed | --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • f1ebb456 by Howard Chu at 2021-03-22T17:31:13+00:00 ITS#9251 make max filter depth configurable -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5365] Library symbol versioning or other help for library transitions
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=5365 --- Comment #8 from Howard Chu <hyc(a)openldap.org> --- HowTo docs here https://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sym… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9251] slapd tries to allocate huge amounts of memory for deeply nested filter
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9251 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED --- Comment #7 from Howard Chu <hyc(a)openldap.org> --- added config keyword in master -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6206] Admin guide appendices or tools in contrib should be better than Ubuntu docs
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=6206 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- (In reply to Gavin Henry from comment #4) > I think these are now them: > > https://ubuntu.com/server/docs/service-ldap Yes, but there is no mention of any auxiliary/contrib stuff on that page at all. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9421] New: SIGSEGV in the MMR synchro
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9421 Issue ID: 9421 Summary: SIGSEGV in the MMR synchro Product: OpenLDAP Version: 2.4.56 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: benjamin.demarteau(a)liege.be Target Milestone: --- We are in the process of migrating from a single outdated node to an up to date MMR cluster. Through this process we write LSC synchronizations from the old server to the new server so we can keep the old server around. Our preliminary tests show that when LSC hammers the ldap using multiple threads while another node is included in the replication, we get segmentation faults with the following backtrace: #0 0x00007f7f578748ef in __strncasecmp_l_avx () from /lib64/libc.so.6 #1 0x000056094a7ca298 in avl_find (root=0x56094bb28820, data=data@entry=0x7f7e74000cd0, fcmp=fcmp@entry=0x56094a7166a0 <oc_index_name_cmp>) at avl.c:545 #2 0x000056094a716bde in oc_bvfind (ocname=0x7f7e74000cd0) at oc.c:186 #3 oc_bvfind (ocname=ocname@entry=0x7f7e74000cd0) at oc.c:178 #4 0x000056094a70ec5a in objectSubClassMatch (matchp=0x7f7e5fff8c8c, flags=256, syntax=<optimized out>, mr=<optimized out>, value=<optimized out>, assertedValue=0x7f7e74000cd0) at schema_prep.c:214 #5 0x000056094a6e9fb9 in ordered_value_match (match=match@entry=0x7f7e5fff8c8c, ad=0x56094bb184e0, mr=mr@entry=0x56094bb09810, flags=flags@entry=256, v1=v1@entry=0x7f7e5810f470, v2=v2@entry=0x7f7e74000cd0, text=0x7f7e5fff8c90) at value.c:693 #6 0x000056094a6ec44d in test_ava_filter (op=op@entry=0x7f7e5fff90c0, e=e@entry=0x56094bb54a88, ava=0x7f7e74000cc8, type=type@entry=163) at filterentry.c:777 #7 0x000056094a6ecfec in test_filter (op=op@entry=0x7f7e5fff90c0, e=e@entry=0x56094bb54a88, f=f@entry=0x7f7e74000d08) at filterentry.c:88 #8 0x000056094a6ecc81 in test_filter_and (flist=<optimized out>, e=0x56094bb54a88, op=0x7f7e5fff90c0) at filterentry.c:879 #9 test_filter (op=op@entry=0x7f7e5fff90c0, e=0x56094bb54a88, f=<optimized out>) at filterentry.c:118 #10 0x00007f7f5382c58f in syncprov_matchops (op=op@entry=0x7f7e5fff9c80, opc=opc@entry=0x7f7e58001808, saveit=saveit@entry=0) at syncprov.c:1393 #11 0x00007f7f5382e37f in syncprov_op_response (op=0x7f7e5fff9c80, rs=<optimized out>) at syncprov.c:2115 #12 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e5fff9c80, rs=rs@entry=0x7f7e5fff9c10) at result.c:508 #13 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e5fff9c80, rs=rs@entry=0x7f7e5fff9c10) at result.c:583 #14 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at result.c:861 #15 0x000056094a7a86fd in mdb_add (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at add.c:435 #16 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e5fff9c80, rs=0x7f7e5fff9c10, which=op_add, oi=0x56094bb8a720, on=<optimized out>) at backover.c:677 #17 0x000056094a73ceab in over_op_func (op=0x7f7e5fff9c80, rs=<optimized out>, which=<optimized out>) at backover.c:730 #18 0x00007f7f5361ff6a in accesslog_response (op=<optimized out>, rs=<optimized out>) at accesslog.c:1877 #19 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e7410fff0, rs=rs@entry=0x7f7e5fffa870) at result.c:508 #20 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e7410fff0, rs=rs@entry=0x7f7e5fffa870) at result.c:583 #21 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at result.c:861 #22 0x000056094a7a86fd in mdb_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:435 #23 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e7410fff0, rs=0x7f7e5fffa870, which=op_add, oi=0x56094bb8a900, on=<optimized out>) at backover.c:677 #24 0x000056094a73ceab in over_op_func (op=0x7f7e7410fff0, rs=<optimized out>, which=<optimized out>) at backover.c:730 #25 0x000056094a6d32bd in fe_op_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:334 #26 0x000056094a6d4139 in do_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at add.c:194 #27 0x000056094a6cbfc0 in connection_operation (ctx=ctx@entry=0x7f7e5fffaab0, arg_v=arg_v@entry=0x7f7e7410fff0) at connection.c:1175 #28 0x000056094a6ccdbe in connection_read_thread (ctx=0x7f7e5fffaab0, argv=0x1a) at connection.c:1311 #29 0x00007f7f5903bead in ldap_int_thread_pool_wrapper (xpool=0x56094bb2a1d0) at tpool.c:696 #30 0x00007f7f57ae414a in start_thread () from /lib64/libpthread.so.0 #31 0x00007f7f57815f23 in clone () from /lib64/libc.so.6 If we take down the second node, we cannot reproduce the segfaults anymore. Let me know if we can provide more information (we can't provide the core dump since it's full of passwords). -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9347] ppolicy: Password policy not applied when pwdMaxAge overflows max int (32-bit)
by openldap-its＠openldap.org 22 Mar '21

22 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9347 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 -- You are receiving this mail because: You are on the CC list for the issue.

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