openldap-bugs

openldap-bugs@openldap.org

1 participants
21509 discussions

(ITS#5685) slapd segfault
by Claude.lecommandeur＠epfl.ch 05 Sep '08

05 Sep '08

Full_Name: Claude Lecommandeur Version: 2.2.13 OS: Redhat AS4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.178.1.102) Hi, slapd segfault on search with a very long filter. /var/log/nessages says : Sep 5 10:50:44 cognac5-mgr kernel: slapd[22263]: segfault at 0000002a978e2000 rip 0000002a96290746 rsp 00000000407ff290 error 6 gdb says : Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1082136928 (LWP 22263)] 0x0000002a96290746 in _IO_default_xsputn_internal () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000002a96290746 in _IO_default_xsputn_internal () from /lib64/tls/libc.so.6 #1 0x0000002a9626d06b in vfprintf () from /lib64/tls/libc.so.6 #2 0x0000002a9628c794 in vsnprintf () from /lib64/tls/libc.so.6 #3 0x0000002a962726b1 in snprintf () from /lib64/tls/libc.so.6 #4 0x000000552aadbd2e in filter2bv_x (op=0x2a99fc76a0, f=Variable "f" is not available. ) at ../../../servers/slapd/filter.c:852 #5 0x000000552aadbce2 in filter2bv_x (op=0x2a99fc76a0, f=Variable "f" is not available. ) at ../../../servers/slapd/filter.c:846 #6 0x000000552aad99e2 in do_search (op=0x2a99fc76a0, rs=0x40800d70) at ../../../servers/slapd/search.c:158 #7 0x000000552aad91b6 in connection_operation (ctx=0x40800e20, arg_v=0x2a99fc76a0) at ../../../servers/slapd/connection.c:1042 #8 0x000000552ab7f44b in ldap_int_thread_pool_wrapper (xpool=Variable "xpool" is not available. ) at ../../../libraries/libldap_r/tpool.c:467 #9 0x0000002a95f0e137 in start_thread () from /lib64/tls/libpthread.so.0 #10 0x0000002a962f3883 in clone () from /lib64/tls/libc.so.6 I am on holliday next week but will be happy to answer questions when I returns. Claude.

1 0

Re: (ITS#5545) Inconsistency in multi-master setup
by ghenry＠suretecsystems.com 04 Sep '08

04 Sep '08

ST(a)itsc.cuhk.edu.hk wrote: > Oops, I tested on both nodes, which is not supposed to do so in > mirrormode, right? Sorry for the trouble caused. > > Thanks. > > Not at the same time, no. The point is to have one node available to the clients at one time and the other in hot standby, whereby your network infrastructure redirects clients if one node goes down etc. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 13 Whiteley Well Place, Inverurie, Aberdeenshire, AB51 4FP.

1 0

(ITS#5684) slapd crashes when adding entries do cn=config with a too large index
by rhafer＠suse.de 04 Sep '08

04 Sep '08

Full_Name: Ralf Haferkamp Version: HEAD, RE24 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.240.108) slapd crashes when trying to add an indexed entry to cn=config with an index larger than the number of sibling entries. E.g. when you have to entries below cn=schema,cn=config (with index {0} an {1}) and try to add cn={3}myschema,cn=schema,... slapd dumps core. I am currently testing a fix that just adjusts the index of the new entry to match the number of sibilings. (Another option would be to error out).

1 0

(ITS#5683) Don't leak syntax oid macro in case of duplicate attribute
by ando＠sys-net.it 04 Sep '08

04 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando p.

1 0

Re: (ITS#5682) Undef objectClass soc_cname not NUL-terminated
by ando＠sys-net.it 04 Sep '08

04 Sep '08

ando(a)sys-net.it wrote: > The soc_cname of undefined objectClasses generated by oc_bvfind_undef() is not > NUL-terminated. A recent commit, where a string-based function operated on it > unvealed the issue. Fixing... For the records: spotted by valgrind. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5682) Undef objectClass soc_cname not NUL-terminated
by ando＠sys-net.it 04 Sep '08

04 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando The soc_cname of undefined objectClasses generated by oc_bvfind_undef() is not NUL-terminated. A recent commit, where a string-based function operated on it unvealed the issue. Fixing... p.

1 0

Re: (ITS#5680) pcache not returning cached entries
by hyc＠symas.com 03 Sep '08

03 Sep '08

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >>>>> The backend server is a Novell eDirectory and the proxy don't have >>>>> information about the complete schema. >>>> I suspect the remote server is returning an objectClass that is unknown >>>> to the proxy; for example, ndsLoginProperties. So, not ours :) >>> I could reproduce the issue by caching an entry with an objectClass not >>> known to the proxy :). So the "right" solution consists in fixing the >>> proxy's schema. Of course, OpenLDAP could inform the proxy >>> administrator with some intelligible message or, even better, try to >>> repair itself (e.g. by checking the remote server's subschemaSubentry). >>> >> Probably not a good idea to do that automagically. Perhaps with a config >> switch. > > Right. I'll fix it. Actually... I think the original patch was fine. I meant, checking the remote server's subschema should be optional... ;) > >> Also, not a good idea to import miscellaneous foreign schema globally; >> we should implement per-database schema instead. > > I think per-database subschema has been on the todolist since ever or so :) And now we have another reason to do it. -- -- 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#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

Howard Chu wrote: >> Right. I'll fix it. > > Actually... I think the original patch was fine. I meant, checking the > remote server's subschema should be optional... ;) Too late :) well, I don't like too much the idea of having yet another fine-tune parameter in config, but this change could impact users that need to proxy well-configured systems and, say, cache entries with huge member lists or so... so better make diversion from original behavior optional, if the original behavior is safe in sane setups. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

(ITS#5681) canonicalize undef objectClass names?
by ando＠sys-net.it 03 Sep '08

03 Sep '08

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Currently, slapd canonicalizes undef (or proxied) attribute names by making them uppercased. It should do the same with undef objectClass names. A patch is coming. p.

1 0

Re: (ITS#5680) pcache not returning cached entries
by ando＠sys-net.it 03 Sep '08

03 Sep '08

hyc(a)symas.com wrote: >>>> The backend server is a Novell eDirectory and the proxy don't have >>>> information about the complete schema. >>> I suspect the remote server is returning an objectClass that is unknown >>> to the proxy; for example, ndsLoginProperties. So, not ours :) >> I could reproduce the issue by caching an entry with an objectClass not >> known to the proxy :). So the "right" solution consists in fixing the >> proxy's schema. Of course, OpenLDAP could inform the proxy >> administrator with some intelligible message or, even better, try to >> repair itself (e.g. by checking the remote server's subschemaSubentry). >> > Probably not a good idea to do that automagically. Perhaps with a config > switch. Right. I'll fix it. > Also, not a good idea to import miscellaneous foreign schema globally; > we should implement per-database schema instead. I think per-database subschema has been on the todolist since ever or so :) p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs