openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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

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