- openldap-bugs - openldap.org

Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by michael＠stroeder.com 27 Apr '17

27 Apr '17

kavyauk(a)gmail.com wrote: > Version: 2.4.33 Note that release 2.4.33 is 4,5 years old. Many fixes have been applied since then. Do you still experience the same problem with recent release 2.4.44? Ciao, Michael.

1 0

(ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
by kavyauk＠gmail.com 27 Apr '17

27 Apr '17

Full_Name: Kavya U K Version: 2.4.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.163.220.19) Our application uses openladp library to LDAP authentication . Intermittently application crashes with below back trace . backtrace =================================== #0 0x008b1266 in raise () from /lib/libc.so.6 #1 0x008b2c31 in abort () from /lib/libc.so.6 #2 0x008aa49d in __assert_fail () from /lib/libc.so.6 #3 0x00a3e056 in ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36 Please let us know how to resolve it

1 0

(ITS#8645) syncrepl configuration error handling
by elecharny＠apache.org 27 Apr '17

27 Apr '17

Full_Name: Emmanuel L.charny Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.154.3.51) The parse_syncrepl_line function (syncrepl.c) returns either 0, -1 or 1. 0 is for success, -1 is for a error, 1 seems to be for a warning (ie a parameter is wrongly configured, but then it's ignored). That's ok, except that in the loop where the parameters are parsed, if one of the parameters in {'retry', 'manageDSAit', 'sizelimit', 'timelimit'} is incorect, the following parameters aren't parsed at all, the fuction return 1. At this point, in the caller function add_syncrepl, we have : rc = parse_syncrepl_line( c, si ); if ( rc == 0 ) { ... } if ( rc < 0 ) { Debug( LDAP_DEBUG_ANY, "failed to add syncinfo\n", 0, 0, 0 ); syncinfo_free( si, 0 ); return 1; } else { Debug( LDAP_DEBUG_CONFIG, "Config: ** successfully added syncrepl %s \"%s\"\n", si->si_ridtxt, BER_BVISNULL( &si->si_bindconf.sb_uri ) ? "(null)" : si->si_bindconf.sb_uri.bv_val, 0 ); ... So here, we will have a message indicating syncrepl has properly be initialized, when many parameters might have been ignored. It seems the proper handling of those wrongly initialized parameters should be to do a 'continue' instead of returning 1, and add a warning in logs. Like : ... else if ( !strncasecmp( c->argv[ i ], RETRYSTR "=", STRLENOF( RETRYSTR "=" ) ) ) { if ( parse_syncrepl_retry( c, c->argv[ i ], si ) ) { continue; /* was return 1; } } Or maybe we just want to return -1 in all cases ?

1 0

(ITS#8644) test064-constraint should wait for slapd to start
by ryan＠openldap.org 25 Apr '17

25 Apr '17

Full_Name: Ryan Tandy Version: 2.4.44 OS: Debian URL: Submission from: (NULL) (24.68.41.160) Submitted by: ryan test064-constraint can occasionally fail if ldapadd runs while slapd is still starting up. https://bugs.debian.org/770890 has links to examples. >>>>> Starting test064-constraint for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Adding basic structure... ldapadd failed (255)! >>>>> test064-constraint failed for hdb (exit 255) Other scripts have an ldapsearch loop that waits for slapd to start, and the same should suffice here.

1 0

Re: (ITS#8592) Double free in sssvlv.c
by kevinanties＠gmail.com 24 Apr '17

24 Apr '17

--f403043eddf896760a054de0b265 Content-Type: text/plain; charset=UTF-8 Why this bug is still not fixed? This is a critical bug for those who enable this overlay. On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Tuesday, February 21, 2017 4:20 AM +0000 kevinanties(a)gmail.com wrote: > > --f403045e3462d25e8f054902b3a3 >> Content-Type: text/plain; charset=UTF-8 >> >> I have submitted to ftp/incoming. The filename is >> kevin-170221-sssvlv.patch. >> > > Please carefully read the contribution web page. Your submission is > clearly missing the IPR notice: > > <http://www.openldap.org/devel/contributing.html#notice> > > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --f403043eddf896760a054de0b265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Why this bug is still not fixed? This is a critical bug fo= r those who enable this overlay.<br></div><div class=3D"gmail_extra"><br><d= iv class=3D"gmail_quote">On Wed, Feb 22, 2017 at 12:09 AM, Quanah Gibson-Mo= unt <span dir=3D"ltr"><<a href=3D"mailto:quanah@symas.com" target=3D"_bl= ank">quanah(a)symas.com</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x">--On Tuesday, February 21, 2017 4:20 AM +0000 <a href=3D"mailto:kevinant= ies(a)gmail.com" target=3D"_blank">kevinanties(a)gmail.com</a> wrote:<br> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> --f403045e3462d25e8f054902b3a3<br> Content-Type: text/plain; charset=3DUTF-8<span class=3D""><br> <br> I have submitted to ftp/incoming. The filename is<br> kevin-170221-sssvlv.patch.<br> </span></blockquote> <br> Please carefully read the contribution web page.=C2=A0 Your submission is c= learly missing the IPR notice:<br> <br> <<a href=3D"http://www.openldap.org/devel/contributing.html#notice" rel= =3D"noreferrer" target=3D"_blank">http://www.openldap.org/devel<wbr>/contri= buting.html#notice</a>><div class=3D"HOEnZb"><div class=3D"h5"><br> <br> Regards,<br> Quanah<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" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>><br> <br> </div></div></blockquote></div><br></div> --f403043eddf896760a054de0b265--

1 0

Re: (ITS#8605) spelling
by quanah＠symas.com 24 Apr '17

24 Apr '17

Hi Josh, Thanks very much! In the future, please remember to CC openldap-its(a)openldap.org, or there will not be a record in the ITS of the submission. ;) --Quanah --On Sunday, April 23, 2017 8:37 PM -0400 Josh Soref <jsoref(a)gmail.com> wrote: > I've uploaded it again: >> ftp ftp.openldap.org > Connected to www.openldap.org. > 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] > 200 UTF8 set to on > User (www.openldap.org:(none)): ftp > 331 Anonymous login ok, send your complete email address as your password > Password: > 230 Anonymous access granted, restrictions apply > ftp> cd incoming > 250 CWD command successful > ftp> dir > 200 PORT command successful > 150 Opening ASCII mode data connection for file list > 226 Transfer complete > ftp> ascii > 200 Type set to A > ftp> put > Local file 0001-spelling-fixes.patch > Remote file josh-soref-170423.patch > 200 PORT command successful > 150 Opening ASCII mode data connection for josh-soref-170423.patch > 226 Transfer complete > ftp: 133503 bytes sent in 1.13Seconds 117.73Kbytes/sec. > ftp> quit > 221 Goodbye -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8205)
by quanah＠symas.com 23 Apr '17

23 Apr '17

--On Sunday, October 25, 2015 10:28 AM +0000 hyc(a)symas.com wrote: > peter(a)adpm.de wrote: >> Hi, >> >> I extended the patch series with a manual page for pbkdf2 >> * >> https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f64 >> 9ca22aeb5ae4 contrib/passwd/pbkdf2: add man page, install it too > > Please use format-patch to submit patches, thanks. If you add .patch to the end of the URL, you can trivially get patches already formatted for use with git. A rather useful trick. ;) --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#8605) spelling
by quanah＠symas.com 23 Apr '17

23 Apr '17

Hi Josh, Still waiting on a git format patch, as per the contribution guidelines: <http://www.openldap.org/devel/contributing.html#formats> Thanks, 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#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 21 Apr '17

21 Apr '17

--On Friday, April 21, 2017 2:26 AM +0100 Howard Chu <hyc(a)symas.com> wrote: >> It's fine for there to be legacy entryCSNs and a contextCSN for serverID >> of 0. However, it is not fine for any master in an MMR setup to have a >> specific serverID of 0. If you're running with serverID's 0-3, I'd >> simply try an ldapmodify on the server with 0 to set its serverID to 4, >> and then do a modification against it, so it generates a new contextCSN >> that gets pushed out to all nodes. > > Performance-wise, it would be better to delete the SID 0 contextCSN value > too. Yeah, definitely not optimal, but less of a worry at the moment. ;) --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#8609) segfault in mods.c - modify_add_values
by hyc＠symas.com 21 Apr '17

21 Apr '17

quanah(a)symas.com wrote: > --On Thursday, April 20, 2017 9:02 PM +0000 henson(a)acm.org wrote: > >>> From: Quanah Gibson-Mount >>> Sent: Thursday, April 20, 2017 8:07 AM >>> >>> You stated previously that you are in 4-way MMR. It's not valid to have >>> a serverID of 0 in an MMR environment (See >>> <http://www.openldap.org/its/index.cgi/?findid=8635>). >> >> Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people >> have serverID's of 0 in their replicated environments, as I don't know >> that I've ever seen that information before. What are the ramifications >> of having a server with an ID of 0 in a replicated environment? What is >> the procedure for remediating the issue? Is it as simple as shutting down >> that server, updating the configuration to have a serverID of 4 and >> restarting it? Or does the database need to be stripped of all CSN's >> which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w >> option on the master and then reloading from ldif on all the replicas? > > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. If you're running with serverID's 0-3, I'd simply > try an ldapmodify on the server with 0 to set its serverID to 4, and then > do a modification against it, so it generates a new contextCSN that gets > pushed out to all nodes. Performance-wise, it would be better to delete the SID 0 contextCSN value too. -- -- 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#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 20 Apr '17

20 Apr '17

--On Thursday, April 20, 2017 9:02 PM +0000 henson(a)acm.org wrote: >> From: Quanah Gibson-Mount >> Sent: Thursday, April 20, 2017 8:07 AM >> >> You stated previously that you are in 4-way MMR. It's not valid to have >> a serverID of 0 in an MMR environment (See >> <http://www.openldap.org/its/index.cgi/?findid=8635>). > > Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people > have serverID's of 0 in their replicated environments, as I don't know > that I've ever seen that information before. What are the ramifications > of having a server with an ID of 0 in a replicated environment? What is > the procedure for remediating the issue? Is it as simple as shutting down > that server, updating the configuration to have a serverID of 4 and > restarting it? Or does the database need to be stripped of all CSN's > which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w > option on the master and then reloading from ldif on all the replicas? It's fine for there to be legacy entryCSNs and a contextCSN for serverID of 0. However, it is not fine for any master in an MMR setup to have a specific serverID of 0. If you're running with serverID's 0-3, I'd simply try an ldapmodify on the server with 0 to set its serverID to 4, and then do a modification against it, so it generates a new contextCSN that gets pushed out to all nodes. --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#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 20 Apr '17

20 Apr '17

> From: Quanah Gibson-Mount > Sent: Thursday, April 20, 2017 8:07 AM > > You stated previously that you are in 4-way MMR. It's not valid to have a > serverID of 0 in an MMR environment (See > <http://www.openldap.org/its/index.cgi/?findid=8635>). Well now, that's quite a fresh ITS 8-/. I'm guessing quite a few people have serverID's of 0 in their replicated environments, as I don't know that I've ever seen that information before. What are the ramifications of having a server with an ID of 0 in a replicated environment? What is the procedure for remediating the issue? Is it as simple as shutting down that server, updating the configuration to have a serverID of 4 and restarting it? Or does the database need to be stripped of all CSN's which have an ID of 0 via slapcat, grep -v, and then slapadd with the -w option on the master and then reloading from ldif on all the replicas?

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 20 Apr '17

20 Apr '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, April 20, 2017 1:34 AM > > those come from master with ServerID 0? Maybe you can find them in > another server's accesslog? Hmm, no, I don't see them in any of the three other accesslogs either. > Would you be able to try the patch I provided earlier on one of your > servers? This one? ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170327-ITS8609-ignore-inv= alid-accesslog-ops.patch Sure, I can drop this in on the master server that has been crashing and = see what happens. Thanks=E2=80=A6

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by quanah＠symas.com 20 Apr '17

20 Apr '17

--On Thursday, April 20, 2017 9:34 AM +0000 okuznik(a)symas.com wrote: > On Wed, Apr 19, 2017 at 01:03:15PM -0700, Paul B. Henson wrote: >> On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote= > : >>> could you post the two accesslog entries (or at least an outline) >>> referenced in the backtrace? >> =20 >> That's weird. I can't find these exact entries. Based on the username, = > I >> found ones that are very close to the timestamp, but ones that match >> these exact timestamps do not exist. Last time Quanah asked me to look >> up the matching accesslog entry from the crash I believe I was able to >> find it. > > Hi Paul, > those come from master with ServerID 0? Maybe you can find them in > another server's accesslog? Hi Paul, You stated previously that you are in 4-way MMR. It's not valid to have a serverID of 0 in an MMR environment (See <http://www.openldap.org/its/index.cgi/?findid=8635>). --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#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 20 Apr '17

20 Apr '17

On Wed, Apr 19, 2017 at 01:03:15PM -0700, Paul B. Henson wrote: > On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ond=C5=99ej Kuzn=C3=ADk wrote= : >> could you post the two accesslog entries (or at least an outline) >> referenced in the backtrace? >=20 > That's weird. I can't find these exact entries. Based on the username, = I > found ones that are very close to the timestamp, but ones that match > these exact timestamps do not exist. Last time Quanah asked me to look > up the matching accesslog entry from the crash I believe I was able to > find it. Hi Paul, those come from master with ServerID 0? Maybe you can find them in another server's accesslog? >> - reqStart=3D20170415103641.000016Z,cn=3Daccesslog >=20 > dn: reqStart=3D20170415103641.000068Z,cn=3Daccesslog > reqDN: uid=3Dbrandonl,ou=3Duser,dc=3Dcpp,dc=3Dedu > reqMod: entryCSN:=3D 20170415103641.599920Z#000000#000#000000 > entryCSN: 20170415103641.599920Z#000000#000#000000 >=20 >> - reqStart=3D20170416103057.000005Z,cn=3Daccesslog >=20 > dn: reqStart=3D20170416103057.000045Z,cn=3Daccesslog > reqDN: uid=3Daaalmora,ou=3Duser,dc=3Dcpp,dc=3Dedu > reqMod: entryCSN:=3D 20170416103057.530384Z#000000#000#000000 > entryCSN: 20170416103057.530384Z#000000#000#000000 >=20 >> I assume you are still running the same code in production, correct? >=20 > Yes. It actually crashed 4 days in a row :(, the two days I provided > backtraces for and then the following two days. Just for something to d= o > I slapcat'd the db and accesslog and reloaded it after the fourth day i= n > case there was some weird mdb corruption or something. It hasn't crashe= d > since, but it crashes randomly so that could be meaningless <sigh>. I > wouldn't think reloaded the db would have affected finding the matching > accesslog entries but that is something different than last time too. > And of course now this is the non-optimized build. Would you be able to try the patch I provided earlier on one of your servers? Thanks, --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 19 Apr '17

19 Apr '17

On Wed, Apr 19, 2017 at 05:37:35PM +0100, Ondřej Kuzník wrote: > could you post the two accesslog entries (or at least an outline) > referenced in the backtrace? That's weird. I can't find these exact entries. Based on the username, I found ones that are very close to the timestamp, but ones that match these exact timestamps do not exist. Last time Quanah asked me to look up the matching accesslog entry from the crash I believe I was able to find it. > - reqStart=20170415103641.000016Z,cn=accesslog dn: reqStart=20170415103641.000068Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170415103641.000068Z reqEnd: 20170415103641.000069Z reqType: modify reqSession: 792228 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=brandonl,ou=user,dc=cpp,dc=edu reqResult: 0 reqMod: eduPersonAffiliation:= reqMod: eduPersonPrimaryAffiliation:= reqMod: cppEduPersonAffiliation:= reqMod: entryCSN:= 20170415103641.599920Z#000000#000#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqMod: modifyTimestamp:= 20170415103641Z reqEntryUUID: 8b33981d-25ee-4f7b-b439-41c273e94b61 entryUUID: b132db96-9ebe-4ee5-9fd2-5257b0c352d2 creatorsName: cn=accesslog createTimestamp: 20170415103641Z entryCSN: 20170415103641.599920Z#000000#000#000000 modifiersName: cn=accesslog modifyTimestamp: 20170415103641Z > - reqStart=20170416103057.000005Z,cn=accesslog dn: reqStart=20170416103057.000045Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20170416103057.000045Z reqEnd: 20170416103057.000046Z reqType: modify reqSession: 54887 reqAuthzID: cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqDN: uid=aaalmora,ou=user,dc=cpp,dc=edu reqResult: 0 reqMod: eduPersonAffiliation:= reqMod: eduPersonPrimaryAffiliation:= reqMod: cppEduPersonAffiliation:= reqMod: entryCSN:= 20170416103057.530384Z#000000#000#000000 reqMod: modifiersName:= cn=idmgmt,ou=user,ou=service,dc=cpp,dc=edu reqMod: modifyTimestamp:= 20170416103057Z reqEntryUUID: 153aa3e7-cc27-48ce-b6f2-e14215348941 entryCSN: 20170416103057.530384Z#000000#000#000000 entryUUID: b0c18fef-134e-4c8e-b073-fcdff58d3d93 creatorsName: cn=accesslog createTimestamp: 20170416103057Z modifiersName: cn=accesslog modifyTimestamp: 20170416103057Z > I assume you are still running the same code in production, correct? Yes. It actually crashed 4 days in a row :(, the two days I provided backtraces for and then the following two days. Just for something to do I slapcat'd the db and accesslog and reloaded it after the fourth day in case there was some weird mdb corruption or something. It hasn't crashed since, but it crashes randomly so that could be meaningless <sigh>. I wouldn't think reloaded the db would have affected finding the matching accesslog entries but that is something different than last time too. And of course now this is the non-optimized build. Thanks...

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by okuznik＠symas.com 19 Apr '17

19 Apr '17

On Sun, Apr 16, 2017 at 06:20:06PM +0000, henson(a)acm.org wrote: > On Mon, Apr 03, 2017 at 02:44:48PM +0100, Howard Chu wrote: >=20 >> You should probably switch to a non-optimized build. The backtrace you >> posted initially had most parameters optimized out, which also makes >> things harder to trace. >=20 > Well, as luck (8-/) would have it, it crashed both yesterday and today > on the non-optimized build. Here are the full backtraces from both > cores, I hope they provide some clue as to what's going on. Let me know > if you want me to do any more post mortem debugging on the cores. Thank= s > much. >=20 >=20 > Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h lda= ps:// ldap://'. > Program terminated with signal SIGSEGV, Segmentation fault. > (gdb) bt full > #6 0x00000000004c84b4 in syncrepl_message_to_op (si=3D0x16e4630, op=3D= 0x7fac037fd730, msg=3D0x7fabfc4a1560) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:2394 > #7 0x00000000004c31cd in do_syncrep2 (op=3D0x7fac037fd730, si=3D0x16e4= 630) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:1013 > bdn =3D {bv_len =3D 44, bv_val =3D 0x7fabfc492bea "reqStart=3D2= 0170415103641.000016Z,cn=3Daccesslog"} >=20 >=20 > Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h lda= ps:// ldap://'. > Program terminated with signal SIGSEGV, Segmentation fault. > (gdb) bt full > #6 0x00000000004c84b4 in syncrepl_message_to_op (si=3D0x1ea8970, op=3D= 0x7fa0b59f1730, msg=3D0x7fa0a012df60) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:2394 > #7 0x00000000004c31cd in do_syncrep2 (op=3D0x7fa0b59f1730, si=3D0x1ea8= 970) > at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/ope= nldap-2.4.44/servers/slapd/syncrepl.c:1013 > bdn =3D {bv_len =3D 44, bv_val =3D 0x7fa0a0422609 "reqStart=3D2= 0170416103057.000005Z,cn=3Daccesslog"} Hi Paul, could you post the two accesslog entries (or at least an outline) referenced in the backtrace? - reqStart=3D20170415103641.000016Z,cn=3Daccesslog - reqStart=3D20170416103057.000005Z,cn=3Daccesslog I assume you are still running the same code in production, correct? Thanks, Ondrej --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8643) include/lber.h contains a typo
by quanah＠symas.com 18 Apr '17

18 Apr '17

--On Tuesday, April 18, 2017 3:19 PM +0000 vl(a)samba.org wrote: > Full_Name: Volker Lendecke > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.22.212.41) > > > Tried to upload the patch to ftp.openldap.org according to > > http://www.openldap.org/devel/contributing.html#patches > > but got permission denied: > ># ftp ftp.openldap.org > Trying 23.92.27.230... > Connected to www.openldap.org. > 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] > Name (ftp.openldap.org:vlendec): ftp > 331 Anonymous login ok, send your complete email address as your password > Password: > 230 Anonymous access granted, restrictions apply > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> put > (local-file) patch.txt > (remote-file) volker-lendecke-170418.txt > local: patch.txt remote: volker-lendecke-170418.txt > 229 Entering Extended Passive Mode (|||64436|) > 550 volker-lendecke-170418.txt: Permission denied > ftp> quit > > > The patch is simple: include/lber.h:176 contains "operarion" instead of > "operation". That should be fixed. Thanks for the report! As noted in the instructions for using FTP, you need to cd to the incoming directory before you can put the patch: % ftp ftp> open ftp.openldap.org User: ftp 331 Guest login ok, send your email address as password. Password: your-email-address Remote system type is UNIX. Using binary mode to transfer files. ftp> cd incoming 250 CWD command successful. ftp> As this is a very trivial typo fix, IPR bits don't need to apply. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8643) include/lber.h contains a typo
by vl＠samba.org 18 Apr '17

18 Apr '17

Full_Name: Volker Lendecke Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.22.212.41) Tried to upload the patch to ftp.openldap.org according to http://www.openldap.org/devel/contributing.html#patches but got permission denied: # ftp ftp.openldap.org Trying 23.92.27.230... Connected to www.openldap.org. 220 ProFTPD 1.3.4a Server (gauss) [::ffff:23.92.27.230] Name (ftp.openldap.org:vlendec): ftp 331 Anonymous login ok, send your complete email address as your password Password: 230 Anonymous access granted, restrictions apply Remote system type is UNIX. Using binary mode to transfer files. ftp> put (local-file) patch.txt (remote-file) volker-lendecke-170418.txt local: patch.txt remote: volker-lendecke-170418.txt 229 Entering Extended Passive Mode (|||64436|) 550 volker-lendecke-170418.txt: Permission denied ftp> quit The patch is simple: include/lber.h:176 contains "operarion" instead of "operation". That should be fixed.

1 0

(ITS#8642) ./configure --without-thread compile failed on git master
by zhu.qunying＠gmail.com 18 Apr '17

18 Apr '17

Full_Name: Zhu, Qunying Version: git master OS: Linux (Slackware63 14.2) URL: Submission from: (NULL) (208.91.114.4) I will get the compile error of this: thr_stub.c:170:1: error: conflicting types for 'ldap_pvt_thread_pool_retract' ldap_pvt_thread_pool_retract ( ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from thr_stub.c:21:0: ../../include/ldap_pvt_thread.h:237:1: note: previous declaration of 'ldap_pvt_thread_pool_retract' was here ldap_pvt_thread_pool_retract LDAP_P(( ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ thr_stub.c:254:1: warning: return type defaults to 'int' [-Wimplicit-int] ldap_pvt_thread_pool_pausecheck( ldap_pvt_thread_pool_t *tpool ) It seems the check in e12ca8b6fed6b8a2526 for "Fixes for multiple threadpool queues" change the API but does not update the thr_stub.c definition.

1 0

Re: (ITS#6874) slapd crashes while modifying a database
by quanah＠symas.com 16 Apr '17

16 Apr '17

For historical reference, this was the config (Considered invalid) that caused the crash. # $Id: slapd.conf.tmp-ofd,v 1.2 2010/12/23 13:21:29 dieter Exp dieter $ #### Schemata, Reihenfolge wegen Abh??ngikeiten u.U. wichtig! ############################## # Globale Anweisungen # ############################## include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/authldap.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/dnszone.schema include /etc/openldap/schema/dhcp.schema include /etc/openldap/schema/ofdconf.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/ofdaddon.schema pidfile /tmp2/ldap1/run/slapd.pid argsfile /tmp2/ldap1/run/slapd.args loglevel 0 threads 160 password-hash {CLEARTEXT} modulepath /usr/lib/openldap/modules moduleload accesslog.la moduleload dynlist.la moduleload memberof.la moduleload refint.la moduleload unique.la TLSCACertificateFile /etc/openldap/ssl/ldapca.pem TLSCertificateFile /etc/openldap/ssl/ldapcert.pem TLSCertificateKeyFile /etc/openldap/ssl/ldapkey.pem access to dn.base="" by * read access to dn.base="cn=Subschema" by * read include /etc/openldap/ofd.acl sizelimit -1 timelimit 4000 # allow bind_v2 ############################### # Config Database # ############################### database config rootdn cn=config rootpw secret ############################## # Erste Database # ############################## database hdb suffix "ou=humans,ou=steuer,o=landesverwaltung niedersachsen,c=de" subordinate advertise rootdn "cn=gen.man,ou=mgr,ou=steuer,o=landesverwaltung niedersachsen,c=de" directory /tmp2/ldap1/human-data checkpoint 4096 5 index default pres,eq index objectclass eq index mail sub,eq index sn sub,eq index cn sub,eq index entryCSN,entryUUID cachesize 5000 idlcachesize 15000 dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/human dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE ############################### # Zweite Database # ############################### database hdb suffix "ou=system,ou=steuer,o=landesverwaltung niedersachsen,c=de" subordinate advertise rootdn "cn=gen.man,ou=mgr,ou=steuer,o=landesverwaltung niedersachsen,c=de" directory /tmp2/ldap1/sys-data checkpoint 4096 5 cachesize 5000 idlcachesize 1500 index objectclass eq index sn,cn,mail eq,sub index entryCSN,entryUUID eq dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/sys dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 syncprov-reloadhint TRUE ########################## # Dritte Database # ########################## database hdb suffix "ou=steuer,o=landesverwaltung niedersachsen,c=de" rootdn "cn=gen.man,ou=mgr,ou=steuer,o=landesverwaltung niedersachsen,c=de" rootpw secret directory /tmp2/ldap1/main-data checkpoint 4096 5 cachesize 5000 idlcachesize 1500 dbconfig set_cachesize 0 68157440 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/main dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq index default pres,eq index mail,telephoneNumber index cn,sn,uid eq,sub index entryUUID,entryCSN eq overlay glue overlay accesslog logdb "cn=log" logops writes overlay syncprov syncprov-checkpoint 100 10 syncprov-reloadhint TRUE ############################ # Log Database # ############################ database hdb suffix "cn=log" directory /tmp2/ldap1/log-data rootdn cn=log checkpoint 10240 5 dbconfig set_cachesize 0 367001600 0 dbconfig set_lg_dir /tmp2/ldap1/log/bdb/log dbconfig set_lg_regionmax 262144 dbconfig set_lg_bsize 2097152 dbconfig set_flags DB_LOG_AUTOREMOVE index objectClass eq index reqStart,entryCSN,reqEnd,reqResult eq overlay syncprov syncprov-nopresent TRUE syncprov-checkpoint 100 10 ############################# # Monitor Database # ############################# database monitor # EOF -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8376)
by quanah＠symas.com 16 Apr '17

16 Apr '17

There are two problems with this ITS: a) It was not submitted for inclusion with the project by the original author (as generally required). I.e., 3rd party submissions are usually rejected. b) It lacks an IPR notice, which must come from the original author. If someone from SuSE can track down the original author, and have them follow up with the IPR information, then we can likely look to include it in a future release. <http://www.openldap.org/devel/contributing.html> may be a useful reference for the SuSE team for future issues. --Quanah --On Saturday, April 15, 2017 3:27 PM +0000 michael(a)stroeder.com wrote: > FWIW: The patch is still available here in openSUSE's package openldap2: > > https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009- > Fix-ldap-host-lookup-ipv6.patch?expand=1 > > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 16 Apr '17

16 Apr '17

On Mon, Apr 03, 2017 at 02:44:48PM +0100, Howard Chu wrote: > You should probably switch to a non-optimized build. The backtrace you > posted initially had most parameters optimized out, which also makes > things harder to trace. Well, as luck (8-/) would have it, it crashed both yesterday and today on the non-optimized build. Here are the full backtraces from both cores, I hope they provide some clue as to what's going on. Let me know if you want me to do any more post mortem debugging on the cores. Thanks much. Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004b8dbb in modify_add_values (e=0x7fac037fca30, mod=0x7fabfc000a90, permissive=0, text=0x7fac037fd000, textbuf=0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { [Current thread is 1 (Thread 0x7fac037fe700 (LWP 1292))] (gdb) bt full #0 0x00000000004b8dbb in modify_add_values (e=0x7fac037fca30, mod=0x7fabfc000a90, permissive=0, text=0x7fac037fd000, textbuf=0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 rc = -67095872 op = 0x5866e0 "add" a = 0x7fac037fc8a0 pmod = {sm_desc = 0x16d53c0, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 34, bv_val = 0x7fabfc000a78 "uid=bran\220\n"}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007fadf301c774 in mdb_modify_internal (op=0x7fac037fd730, tid=0x1a993c0, modlist=0x7fabfc000a50, e=0x7fac037fca30, text=0x7fac037fd000, textbuf=0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:137 rc = 32684 err = 0 mod = 0x7fabfc000a90 ml = 0x7fabfc000a90 save_attrs = 0x7fabfc0032c0 ap = 0x7fac00000000 glue_attr_delete = 0 got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007fadf301e5f2 in mdb_modify (op=0x7fac037fd730, rs=0x7fac037fcfe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:624 mdb = 0x7fadf7dbb010 e = 0x7fabfc003270 manageDSAit = 2 00\000\340\317\177\003\254\177\000\000\060\327\177\003\254\177\000\000 \313\177\003\254\177\000\000\000\000\000\000\260\000\000\000 \313\177\003\254\177\000\000\324\024\214\367\000\000\000\000(&\000\374\253\177\000\000\060\327\177\003\254\177\000\000p-n\001\000\000\000\000P/n\001\000\000\000\000\320%\000\374\253\177\000\000\370%\000\374\253\177\000\000`\322\177\003\254\177\000\000"... textlen = 256 txn = 0x1a993c0 opinfo = {moi_oe = {oe_next = {sle_next = 0x7fac037fcf90}, oe_key = 0x7fadf7dbb010}, moi_txn = 0x1a993c0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fac037fc9e0 dummy = {e_id = 171976, e_name = {bv_len = 34, bv_val = 0x7fabfc003240 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, e_nname = {bv_len = 34, bv_val = 0x7fabfc003d20 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, e_attrs = 0x7fac2442b588, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fabfc003270} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x7fabfc0009d0, 0x50, 0x0, 0x7fac037fc800} num_ctrls = 0 numads = 57 #3 0x00000000004dbc55 in overlay_op_walk (op=0x7fac037fd730, rs=0x7fac037fcfe0, which=op_modify, oi=0x16e2b90, on=0x0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:677 func = 0x7fadf323ddd8 <bi+88> rc = 32768 #4 0x00000000004dbea0 in over_op_func (op=0x7fac037fd730, rs=0x7fac037fcfe0, which=op_modify) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:730 oi = 0x16e2b90 on = 0x16e3d20 be = 0x16d4b60 db = {bd_info = 0x7fadf323dd80 <bi>, bd_self = 0x16d4b60, ts 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0x16d3bf0, be_nsuffix = 0x16d4270, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x16d4490 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootndn = {bv_len = 25, bv_val = 0x16d44e0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootpw = { bv_len = 14, bv_val = 0x16a7a30 "XXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x16d3b20, be_acl = 0x16d5eb0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x19966a0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x16e3970, be_pb = 0x0, be_cf_ocs = 0x7fadf323dac0 <mdbocs>, be_private = 0x7fadf7dbb010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7fac037fcfb0, sc_response = 0x4daa2c <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x16e2b90} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x00000000004dc003 in over_op_modify (op=0x7fac037fd730, rs=0x7fac037fcfe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:769 No locals. #6 0x00000000004c84b4 in syncrepl_message_to_op (si=0x16e4630, op=0x7fac037fd730, msg=0x7fabfc4a1560) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:2394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4c7516 <syncrepl_message_to_op>}, oe_si = 0x16e4630} ber = 0x7fabfc4a76a0 modlist = 0x7fabfc498e20 ls = 0x7dfc40 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7fac037fca80 "modify/delete: eduPersonAffiliation: no such attribute", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x7fabfc0025a0, sc_response = 0x4cfda6 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0xa <error: Cannot access memory at address 0xa> txtbuf = "\220\320\177\003\254\177\000\000\000\321\177\003\254\177\000\000\300\320\177\003\254\177\000\000\030\000\000\000\060\000\000\000p\321\177\003\254\177\000\000\260\320\177\003\254\177\000\000\000\000\000\000\003\000\000\000 \000\000\374\253\177\000\000\377\377\377\377\377\377\377\377\000\000\000\017\000\000\000\000\257\350\377+\254\177\000\000\000\000\000\000\000\000\000\000`\321\177\003\254\177\000\000\000\000\000\000\000\000\000\000\257\350\377+\254\177", '\000' <repeats 11 times>, "\347\177\003\254\177\000\000P\347M", '\000' <repeats 13 times>, "`\322\177\003\254\177\000\000OOq\374\253\177\000\000@Oq\374\253\177\000\000`\325e\001\000\000\000\000OOq\374\253\177\000\000HOq\374\253\177\000\000\000\000\000\000\000\000\000\000"... textlen = 256 bdn = {bv_len = 34, bv_val = 0x7fabfc492c3c "uid=brandonl,ou=user,dc=cpp,dc=edu"} dn = {bv_len = 34, bv_val = 0x7fabfc000d30 "\220\022"} ndn = {bv_len = 34, bv_val = 0x7fabfc000db0 "p\023"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7fabfc41f360 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #7 0x00000000004c31cd in do_syncrep2 (op=0x7fac037fd730, si=0x16e4630) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1013 match = 0 syncUUID = {{bv_len = 16, bv_val = 0x7fabfc4c8cd7 "7\245|\231:\352AM\246\305\066\037i&\201\232"}, { bv_len = 0, bv_val = 0x3000000020 <error: Cannot access memory at address 0x3000000020>}} cookie = {bv_len = 15, bv_val = 0x7fabfc4c8ce9 "rid=003,sid=003"} rctrls = 0x7fabfc49f8f0 rctrlp = 0x7fabfc492de0 bdn = {bv_len = 44, bv_val = 0x7fabfc492bea "reqStart=20170415103641.000016Z,cn=accesslog"} si_tag = 140376648999836 entry = 0x7fabfc49f8f8 punlock = -1 syncstate = 1 retdata = 0x570e74 retoid = 0x7fadf6ac95c0 "" syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "ЌL\374\253\177\000\000\370\214L\374\253\177\000\000\370\214L\374\253\177", '\000' <repeats 26 times>, "\020\000\000\000\254\177\000\000\060\327\177\003\254\177\000\000\200\323\177\003\254\177\000\000\260Э\367\255\177\000\000\030\n\000\374\001\000\000\000\000\061~\000\000\000\000\000\200\323\177\003\254\177\000\000\260Э\367\255\177\000\000H\327\177\003\254\177\000\000 \v\020\024\254\177\000\000\000\324\177\003\254\177\000\000\377J\260\367\255\177\000\000\300\323\177\003\001\000\000\000,\324\177\003\254\177\000\000\060\327\177\003\001\000\000\000\020\t\020"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7fac037fd2e0 msg = 0x7fabfc4a1560 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 3, octet_str = {bv_len = 15, bv_val = 0x7fabfc714f40 "rid=003,sid=003"}, sid = 3, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7fabfc40cfe0, sids = 0x7fabfc4b99f0, numcsns = 4, rid = 3, octet_str = { bv_len = 183, bv_val = 0x7fabfc41b880 "rid=003,sid=000,csn=20170415103641.410645Z#000000#000#000000;20151030223206.483980Z#000000#001#000000;20160115030222.053144Z#000000#002#000000;20170406033805.626505Z#000000#003#000000"}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 1426881987 tout_p = 0x7fac037fd210 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #8 0x00000000004c54c8 in do_syncrepl (ctx=0x7fac037fdbc0, arg=0x16e4b10) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1564 rtask = 0x16e4b10 si = 0x16e4630 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x568650 ""}, c_peer_name = {bv_len = 0, bv_val = 0x568650 ""}, c_listener = 0x570900 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x45801c <slap_send_ldap_result>, c_send_search_entry = 0x458cf0 <slap_send_search_entry>, c_send_search_reference = 0x45b0d8 <slap_send_search_reference>, c_send_ldap_extended = 0x45886d <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x458ade <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fac037fd8a0, o_tag = 102, o_time = 1492252601, o_tincr = 74, o_bd = 0x7fac037fcc90, o_req_dn = {bv_len = 34, bv_val = 0x7fabfc492e70 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, o_req_ndn = {bv_len = 34, bv_val = 0x7fabfc492ea0 "uid=brandonl,ou=user,dc=cpp,dc=edu"}, o_request = {oq_add = { rs_modlist = 0x7fabfc000a50, rs_e = 0x1}, oq_bind = {rb_method = -67106224, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7fabfc000a50}, oq_modify = { rs_mods = {rs_modlist = 0x7fabfc000a50, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7fabfc000a50, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = -67106224, rs_deref = 32683, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = -67106224}, oq_cancel = {rs_msgid = -67106224}, oq_extended = {rs_reqoid = { bv_len = 140376643996240, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 140376643996240, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7fac037fd9f0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 25, bv_val = 0x16d4490 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ndn = { bv_len = 25, bv_val = 0x16d44e0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7fabfc0025d0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fabfc492ed0 "20170415103641.599920Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fac037fc9e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 3, oh_conn = 0x7fac037fd470, oh_msgid = 0, oh_protocol = 0, oh_tid = 140376769816320, oh_threadctx = 0x7fac037fdbc0, oh_tmpmemctx = 0x7fabfc0009d0, oh_tmpmfuncs = 0x7dfb80 <slap_sl_mfuncs>, oh_counters = 0x8156c0 <slap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7fac037fd260, 0x0 <repeats 14 times>}} op = 0x7fac037fd730 rc = 0 dostop = 0 s = 13 i = -141804259 defer = 1 fail = 0 freeinfo = 0 be = 0x16d4b60 #9 0x0000000000440411 in connection_read_thread (ctx=0x7fac037fdbc0, argv=0xd) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/connection.c:1296 rc = 0 cri = {op = 0x0, func = 0x4c4ec6 <do_syncrepl>, arg = 0x16e4b10, ctx = 0x7fac037fdbc0, nullop = 0} s = 13 #10 0x00007fadf7adba4b in ldap_int_thread_pool_wrapper (xpool=0x1667330) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 pool = 0x1667330 task = 0x7fac0c339570 work_list = 0x16673c8 ctx = {ltu_id = 140376769816320, ltu_key = {{ltk_key = 0x43f808 <conn_counter_init>, ltk_data = 0x7fabfc0008c0, ltk_free = 0x43f65a <conn_counter_destroy>}, { ltk_key = 0x4ba0e3 <slap_sl_mem_init>, ltk_data = 0x7fabfc0009d0, ltk_free = 0x4b9f08 <slap_sl_mem_destroy>}, {ltk_key = 0x1996710, ltk_data = 0x7fabfc100a20, ltk_free = 0x7fadf303113d <mdb_reader_free>}, {ltk_key = 0x7fadf3025bce <search_stack>, ltk_data = 0x7fac00ffc010, ltk_free = 0x7fadf3025bab <search_stack_free>}, { ltk_key = 0x7fadf30224aa <scope_chunk_get>, ltk_data = 0x7fabfc1028b0, ltk_free = 0x7fadf3022462 <scope_chunk_free>}, {ltk_key = 0x45c638 <slap_op_free>, ltk_data = 0x7fabf456a930, ltk_free = 0x45c58b <slap_op_q_destroy>}, {ltk_key = 0x178fe70, ltk_data = 0x7fabfc49f9a0, ltk_free = 0x7fadf303113d <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7fabf44f5db0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 948 hash = 3735031732 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x00007fadf7124494 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x00007fadf6817edd in clone () from /lib64/libc.so.6 No symbol table info available. Core was generated by `/usr/lib64/openldap/slapd -u ldap -g ldap -h ldaps:// ldap://'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00000000004b8dbb in modify_add_values (e=0x7fa0b59f0a30, mod=0x7fa0a0000980, permissive=0, text=0x7fa0b59f1000, textbuf=0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 61 if ( !BER_BVISNULL( &mod->sm_values[mod->sm_numvals] )) { [Current thread is 1 (Thread 0x7fa0b59f2700 (LWP 10464))] (gdb) bt full #0 0x00000000004b8dbb in modify_add_values (e=0x7fa0b59f0a30, mod=0x7fa0a0000980, permissive=0, text=0x7fa0b59f1000, textbuf=0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/mods.c:61 rc = -1610599912 op = 0x5866e0 "add" a = 0x7fa0b59f08a0 pmod = {sm_desc = 0x1e9a3c0, sm_values = 0x0, sm_nvalues = 0x0, sm_numvals = 0, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 34, bv_val = 0x7fa0a0000968 "uid=aaal\200\t"}} __PRETTY_FUNCTION__ = "modify_add_values" #1 0x00007fa277718774 in mdb_modify_internal (op=0x7fa0b59f1730, tid=0x225e3c0, modlist=0x7fa0a0000940, e=0x7fa0b59f0a30, text=0x7fa0b59f1000, textbuf=0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", textlen=256) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:137 rc = 32672 err = 0 mod = 0x7fa0a0000980 ml = 0x7fa0a0000980 save_attrs = 0x7fa0a0003218 ap = 0x7fa000000000 glue_attr_delete = 0 got_delete = 0 __PRETTY_FUNCTION__ = "mdb_modify_internal" #2 0x00007fa27771a5f2 in mdb_modify (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/back-mdb/modify.c:624 mdb = 0x7fa27c4b7010 e = 0x7fa0a00031c8 manageDSAit = 2 \000\340\017\237\265\240\177\000\000\060\027\237\265\240\177\000\000 \v\237\265\240\177\000\000\000\000\000\000\260\000\000\000 \v\237\265\240\177\000\000\324\324\373{\000\000\000\000\030%\000\240\240\177\000\000\060\027\237\265\240\177\000\000p}\352\001\000\000\000\000P\177\352\001\000\000\000\000\300$\000\240\240\177\000\000\350$\000\240\240\177\000\000`\022\237\265\240\177\000\000"... textlen = 256 txn = 0x225e3c0 opinfo = {moi_oe = {oe_next = {sle_next = 0x7fa0b59f0f90}, oe_key = 0x7fa27c4b7010}, moi_txn = 0x225e3c0, moi_ref = 1, moi_flag = 0 '\000'} moi = 0x7fa0b59f09e0 dummy = {e_id = 200434, e_name = {bv_len = 34, bv_val = 0x7fa0a0003198 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, e_nname = {bv_len = 34, bv_val = 0x7fa0a0003ce0 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, e_attrs = 0x7fa098ba4938, e_ocflags = 256, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fa0a00031c8} preread_ctrl = 0x0 postread_ctrl = 0x0 ctrls = {0x0, 0x0, 0x7fa0a00008c0, 0x50, 0x0, 0x7fa0b59f0800} num_ctrls = 0 numads = 57 #3 0x00000000004dbc55 in overlay_op_walk (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0, which=op_modify, oi=0x1ea7b90, on=0x0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:677 func = 0x7fa277939dd8 <bi+88> rc = 32768 #4 0x00000000004dbea0 in over_op_func (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0, which=op_modify) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:730 oi = 0x1ea7b90 on = 0x1ea8d20 be = 0x1e99b60 db = {bd_info = 0x7fa277939d80 <bi>, bd_self = 0x1e99b60, ts 14 times>, "\001", be_flags = 563464, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 64}, be_suffix = 0x1e98bf0, be_nsuffix = 0x1e99270, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 25, bv_val = 0x1e99490 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootndn = {bv_len = 25, bv_val = 0x1e994e0 "cn=ldaproot,dc=cpp,dc=edu"}, be_rootpw = { bv_len = 14, bv_val = 0x1e6ca30 "XXXXXXXXXXXX"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = -1, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x1e98b20, be_acl = 0x1e9aeb0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x215b6a0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = { __prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x1ea8970, be_pb = 0x0, be_cf_ocs = 0x7fa277939ac0 <mdbocs>, be_private = 0x7fa27c4b7010, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7fa0b59f0fb0, sc_response = 0x4daa2c <over_back_response>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x1ea7b90} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #5 0x00000000004dc003 in over_op_modify (op=0x7fa0b59f1730, rs=0x7fa0b59f0fe0) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/backover.c:769 No locals. #6 0x00000000004c84b4 in syncrepl_message_to_op (si=0x1ea8970, op=0x7fa0b59f1730, msg=0x7fa0a012df60) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:2394 oes = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x4c7516 <syncrepl_message_to_op>}, oe_si = 0x1ea8970} ber = 0x7fa0a029eb70 modlist = 0x7fa0a0127460 ls = 0x7dfc40 <accesslog_sc> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x7fa0b59f0a80 "modify/delete: eduPersonAffiliation: no such attribute", sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = { r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} cb = {sc_next = 0x7fa0a0002490, sc_response = 0x4cfda6 <null_callback>, sc_cleanup = 0x0, sc_writewait = 0x0, sc_private = 0x0} text = 0xa <error: Cannot access memory at address 0xa> txtbuf = "\220\020\237\265\240\177\000\000\000\021\237\265\240\177\000\000\300\020\237\265\240\177\000\000\030\000\000\000\060\000\000\000p\021\237\265\240\177\000\000\260\020\237\265\240\177\000\000\000\000\000\000\003\000\000\000 \000\000\240\240\177\000\000\377\377\377\377\377\377\377\377\000\000\000\017\000\000\000\000?\034\237\266\240\177\000\000\000\000\000\000\000\000\000\000`\021\237\265\240\177\000\000\000\000\000\000\000\000\000\000?\034\237\266\240\177", '\000' <repeats 11 times>, "'\237\265\240\177\000\000P\347M", '\000' <repeats 13 times>, "`\022\237\265\240\177\000\000\177\233\023\240\240\177\000\000p\233\023\240\240\177\000\000`%\342\001\000\000\000\000\177\233\023\240\240\177\000\000x\233\023\240\240\177\000\000\000\000\000\000\000\000\000\000"... textlen = 256 bdn = {bv_len = 34, bv_val = 0x7fa0a042265b "uid=aaalmora,ou=user,dc=cpp,dc=edu"} dn = {bv_len = 34, bv_val = 0x7fa0a0000c20 "\310\021"} ndn = {bv_len = 34, bv_val = 0x7fa0a0000ca0 "\250\022"} bv = {bv_len = 0, bv_val = 0x0} bv2 = {bv_len = 0, bv_val = 0x0} bvals = 0x7fa0a0106580 rdn = {bv_len = 0, bv_val = 0x0} sup = {bv_len = 0, bv_val = 0x0} prdn = {bv_len = 0, bv_val = 0x0} nrdn = {bv_len = 0, bv_val = 0x0} psup = {bv_len = 0, bv_val = 0x0} nsup = {bv_len = 0, bv_val = 0x0} rc = 0 deleteOldRdn = 0 freeReqDn = 1 do_graduate = 1 #7 0x00000000004c31cd in do_syncrep2 (op=0x7fa0b59f1730, si=0x1ea8970) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1013 match = 0 syncUUID = {{bv_len = 16, bv_val = 0x7fa0a0144147 "4w\232m2\230F>\273\200\032\350\227o\252i"}, { bv_len = 0, bv_val = 0x3000000020 <error: Cannot access memory at address 0x3000000020>}} cookie = {bv_len = 15, bv_val = 0x7fa0a0144159 "rid=001,sid=001"} rctrls = 0x7fa0a0111800 rctrlp = 0x7fa0a0157460 bdn = {bv_len = 44, bv_val = 0x7fa0a0422609 "reqStart=20170416103057.000005Z,cn=accesslog"} si_tag = 140327924125852 entry = 0x7fa0a0111808 punlock = -1 syncstate = 1 retdata = 0x570e74 retoid = 0x7fa27b1c55c0 "" syncUUIDs = 0x0 len = 15 berbuf = { buffer = "\002\000\001", '\000' <repeats 29 times>, "@A\024\240\240\177\000\000hA\024\240\240\177\000\000hA\024\240\240\177", '\000' <repeats 26 times>, "\017\000\000\000\240\177\000\000\060\027\237\265\240\177\000\000\200\023\237\265\240\177\000\000\260\220\035|\242\177\000\000\b\t\000\240\001\000\000\000\000\061~\000\000\000\000\000\200\023\237\265\240\177\000\000\260\220\035|\242\177\000\000H\027\237\265\240\177\000\000 \v\020\230\240\177\000\000\000\024\237\265\240\177\000\000\377\n |\242\177\000\000\300\023\237\265\001\000\000\000,\024\237\265\240\177\000\000\060\027\237\265\001\000\000\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <error: Cannot access memory at address 0x10002>} ber = 0x7fa0b59f12e0 msg = 0x7fa0a012df60 syncCookie = {ctxcsn = 0x0, sids = 0x0, numcsns = 0, rid = 1, octet_str = {bv_len = 15, bv_val = 0x7fa0a0139b70 "rid=001,sid=001"}, sid = 1, sc_next = {stqe_next = 0x0}} syncCookie_req = {ctxcsn = 0x7fa0a04230d0, sids = 0x7fa0a012bb00, numcsns = 4, rid = 1, octet_str = { bv_len = 183, bv_val = 0x7fa0a015e3f0 "rid=001,sid=000,csn=20170416081903.399068Z#000000#000#000000;20170416051743.054642Z#000000#001#000000;20160115030222.053144Z#000000#002#000000;20170416043935.843860Z#000000#003#000000"}, sid = 0, sc_next = {stqe_next = 0x0}} rc = 0 err = 0 modlist = 0x0 m = 1426881987 tout_p = 0x7fa0b59f1210 tout = {tv_sec = 0, tv_usec = 0} refreshDeletes = 0 empty = "empty" __PRETTY_FUNCTION__ = "do_syncrep2" #8 0x00000000004c54c8 in do_syncrepl (ctx=0x7fa0b59f1bc0, arg=0x1ea3e70) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/syncrepl.c:1564 rtask = 0x1ea3e70 si = 0x1ea8970 conn = {c_struct_state = SLAP_C_UNINITIALIZED, c_conn_state = SLAP_C_INVALID, c_conn_idx = -1, c_sd = 0, c_close_reason = 0x0, c_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_sb = 0x0, c_starttime = 0, c_activitytime = 0, c_connid = 18446744073709551615, c_peer_domain = {bv_len = 0, bv_val = 0x568650 ""}, c_peer_name = {bv_len = 0, bv_val = 0x568650 ""}, c_listener = 0x570900 <dummy_list>, c_sasl_bind_mech = {bv_len = 0, bv_val = 0x0}, c_sasl_dn = { bv_len = 0, bv_val = 0x0}, c_sasl_authz_dn = {bv_len = 0, bv_val = 0x0}, c_authz_backend = 0x0, c_authz_cookie = 0x0, c_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = { bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, c_protocol = 0, c_ops = { stqh_first = 0x0, stqh_last = 0x0}, c_pending_ops = {stqh_first = 0x0, stqh_last = 0x0}, c_write1_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write1_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_write2_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, c_write2_cv = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\000' <repeats 47 times>, __align = 0}, c_currentber = 0x0, c_writers = 0, c_writing = 0 '\000', c_sasl_bind_in_progress = 0 '\000', c_writewaiter = 0 '\000', c_is_udp = 0 '\000', c_is_tls = 0 '\000', c_needs_tls_accept = 0 '\000', c_sasl_layers = 0 '\000', c_sasl_done = 0 '\000', c_sasl_authctx = 0x0, c_sasl_sockctx = 0x0, c_sasl_extra = 0x0, c_sasl_bindop = 0x0, c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_count = 0, ps_cookie = 0, ps_cookieval = {bv_len = 0, bv_val = 0x0}}, c_n_ops_received = 0, c_n_ops_executing = 0, c_n_ops_pending = 0, c_n_ops_completed = 0, c_n_get = 0, c_n_read = 0, c_n_write = 0, c_extensions = 0x0, c_clientfunc = 0x0, c_clientarg = 0x0, c_send_ldap_result = 0x45801c <slap_send_ldap_result>, c_send_search_entry = 0x458cf0 <slap_send_search_entry>, c_send_search_reference = 0x45b0d8 <slap_send_search_reference>, c_send_ldap_extended = 0x45886d <slap_send_ldap_extended>, c_send_ldap_intermediate = 0x458ade <slap_send_ldap_intermediate>} opbuf = {ob_op = {o_hdr = 0x7fa0b59f18a0, o_tag = 102, o_time = 1492338657, o_tincr = 65, o_bd = 0x7fa0b59f0c90, o_req_dn = {bv_len = 34, bv_val = 0x7fa0a0160390 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, o_req_ndn = {bv_len = 34, bv_val = 0x7fa0a0127430 "uid=aaalmora,ou=user,dc=cpp,dc=edu"}, o_request = {oq_add = { rs_modlist = 0x7fa0a0000940, rs_e = 0x1}, oq_bind = {rb_method = -1610610368, rb_cred = { bv_len = 1, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = { bv_len = 0, bv_val = 0x0}}, oq_compare = {rs_ava = 0x7fa0a0000940}, oq_modify = { rs_mods = {rs_modlist = 0x7fa0a0000940, rs_no_opattrs = 1 '\001'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x7fa0a0000940, rs_no_opattrs = 1 '\001'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x0}, rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = -1610610368, rs_deref = 32672, rs_slimit = 1, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val = 0x0}}, oq_abandon = { rs_msgid = -1610610368}, oq_cancel = {rs_msgid = -1610610368}, oq_extended = {rs_reqoid = { bv_len = 140327855851840, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = { bv_len = 140327855851840, bv_val = 0x1 <error: Cannot access memory at address 0x1>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = { bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 1 '\001', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 14 times>, "\002", '\000' <repeats 16 times>, o_controls = 0x7fa0b59f19f0, o_authz = {sai_method = 0, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 25, bv_val = 0x1e99490 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ndn = { bv_len = 25, bv_val = 0x1e994e0 "cn=ldaproot,dc=cpp,dc=edu"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x7fa0a00024c0, o_ctrls = 0x0, o_csn = {bv_len = 40, bv_val = 0x7fa0a0109a60 "20170416103057.530384Z#000000#000#000000"}, o_private = 0x0, o_extra = {slh_first = 0x7fa0b59f09e0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 0, oh_connid = 1, oh_conn = 0x7fa0b59f1470, oh_msgid = 0, oh_protocol = 0, oh_tid = 140328218601216, oh_threadctx = 0x7fa0b59f1bc0, oh_tmpmemctx = 0x7fa0a00008c0, oh_tmpmfuncs = 0x7dfb80 <slap_sl_mfuncs>, oh_counters = 0x8156c0 <slap_counters>, oh_log_prefix = "conn=-1 op=0", '\000' <repeats 243 times>, oh_extensions = 0x0}, ob_controls = { 0x0 <repeats 17 times>, 0x7fa0b59f1260, 0x0 <repeats 14 times>}} op = 0x7fa0b59f1730 rc = 0 dostop = 0 s = 18 i = 2080111901 defer = 1 fail = 0 freeinfo = 0 be = 0x1e99b60 #9 0x0000000000440411 in connection_read_thread (ctx=0x7fa0b59f1bc0, argv=0x12) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/servers/slapd/connection.c:1296 rc = 0 cri = {op = 0x0, func = 0x4c4ec6 <do_syncrepl>, arg = 0x1ea3e70, ctx = 0x7fa0b59f1bc0, nullop = 0} s = 18 #10 0x00007fa27c1d7a4b in ldap_int_thread_pool_wrapper (xpool=0x1e2c330) at /var/lib/portage/tmp/portage/net-nds/openldap-2.4.44-r1/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 pool = 0x1e2c330 task = 0x7fa0b0000e40 work_list = 0x1e2c3c8 ctx = {ltu_id = 140328218601216, ltu_key = {{ltk_key = 0x4ba0e3 <slap_sl_mem_init>, ltk_data = 0x7fa0a00008c0, ltk_free = 0x4b9f08 <slap_sl_mem_destroy>}, {ltk_key = 0x215b710, ltk_data = 0x7fa0a0ba3eb0, ltk_free = 0x7fa27772d13d <mdb_reader_free>}, { ltk_key = 0x7fa277721bce <search_stack>, ltk_data = 0x7fa096fff010, ltk_free = 0x7fa277721bab <search_stack_free>}, {ltk_key = 0x7fa27771e4aa <scope_chunk_get>, ltk_data = 0x7fa0a0ba5d40, ltk_free = 0x7fa27771e462 <scope_chunk_free>}, { ltk_key = 0x43f808 <conn_counter_init>, ltk_data = 0x7fa0a012d4f0, ltk_free = 0x43f65a <conn_counter_destroy>}, {ltk_key = 0x45c638 <slap_op_free>, ltk_data = 0x7fa0a825ab60, ltk_free = 0x45c58b <slap_op_q_destroy>}, {ltk_key = 0x1f54e70, ltk_data = 0x7fa0a01c3fa0, ltk_free = 0x7fa27772d13d <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x7fa09c04d880, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 24 times>}} kctx = 0x0 i = 32 keyslot = 634 hash = 3535879802 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x00007fa27b820494 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #12 0x00007fa27af13edd in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8641) LBER_OPT_MEMORY_FNS not working
by Hallvard B Furuseth 16 Apr '17

16 Apr '17

This works as intended: ber_int_memory_fns is only used when passing ctx!=NULL to ber_memalloc_x() & co. slapd/sl_malloc.c does this. ber_memalloc() & co do not use it: As you say, they pass ctx=NULL. Closing this ITS.

1 0

(ITS#8641) LBER_OPT_MEMORY_FNS not working
by wwindcloud＠gmail.com 16 Apr '17

16 Apr '17

Full_Name: Version: All Version OS: Linux URL: Submission from: (NULL) (2001:ce0:2201:83a:7daa:5345:459e:3cec) LBER_OPT_MEMORY_FNS doesn't work at all. In memory.c, it was checking the presence of both ber_int_memory_fns and ctx the same time. However ctx was default to NULL all the time, so that's making this option not working at all. I suggest removing all ctx == NULL in memory.c, that way LBER_OPT_MEMORY_FNS should work as intended. Right now, it's unusable. Thanks.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs