- openldap-bugs - openldap.org

Re: (ITS#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 21 Nov '07

21 Nov '07

tis 2007-11-20 klockan 07:09 -0800 skrev Howard Chu: > Dan.Oscarsson(a)tietoenator.com wrote: > > If this looks correct to you, what code should I add to fix it? > > It would be better if one of you who knows the code better than me could > > do that. I can test and see if it works. > > > Thanks for your investigation; this explanation makes sense. You can test this > simply by disabling the statement in bdb_cache_modrdn() which sets the NO_KIDS > flags: I have tested and it fixed my reduced test case. Running full test still failes. So I suspected it might have to do with CACHE_ENTRY_NO_GRANDKIDS and tested by removing the test for CACHE_ENTRY_NO_GRANDKIDS in dn2id.c *************** *** 1044,1058 **** if ( cx->prefix == DN_SUBTREE_PREFIX ) { bdb_idl_append( cx->ids, cx->tmp ); cx->need_sort = 1; ! /*if ( !(cx->ei->bei_state & CACHE_ENTRY_NO_GRANDKIDS)) {*/ ! { to get it to go down in the tree. This time even my full test works, from what I can see. Though this may not be the correct way to do it, and I do not know if something else may go wrong. It looks like the setting and usage of CACHE_ENTRY_NO_GRANDKIDS and CACHE_ENTRY_NO_KIDS have to be looked over. From what I can see they are only used in cache.c, dn2id.c and modrdn.c in back-bdb/hdb. Should I try something else? Regards, Dan -- Dan Oscarsson TietoEnator Email: Dan.Oscarsson(a)tietoenator.com Box 85 201 20 Malmo, Sweden

1 0

Re: (ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 21 Nov '07

21 Nov '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On November 15, 2007 9:22:41 PM +0000 dieter(a)dkluenter.de wrote: > >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.231.219) > > Dieter, > > Can you confirm one way or the other if the fix in HEAD from > Pierangelo solved your issue? I just did a cvs update of HEAD and did a few tests. As I get now errors it seems that this ITS is solved now. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#5239) Ordered indexing for integers (Enhancement)
by hyc＠OpenLDAP.org 20 Nov '07

20 Nov '07

Full_Name: Howard Chu Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Support for ordered indexing of integer attributes is now in HEAD.

1 0

Re: (ITS#5235) ppolicy leads to segfault
by quanah＠zimbra.com 20 Nov '07

20 Nov '07

--On November 15, 2007 9:22:41 PM +0000 dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.231.219) Dieter, Can you confirm one way or the other if the fix in HEAD from Pierangelo solved your issue? Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5238) test050-syncrepl-multimaster only tests with 2 slapd instances
by ghenry＠suretecsystems.com 20 Nov '07

20 Nov '07

<quote who="richton(a)nbcs.rutgers.edu"> > HEAD test050 succeeds, Fedora 8, x86_64. Just tested again. Same here on both platforms.

1 0

Re: (ITS#5238) test050-syncrepl-multimaster only tests with 2 slapd instances
by richton＠nbcs.rutgers.edu 20 Nov '07

20 Nov '07

HEAD test050 succeeds, Fedora 8, x86_64.

1 0

(ITS#5238) test050-syncrepl-multimaster only tests with 2 slapd instances
by ghenry＠OpenLDAP.org 20 Nov '07

20 Nov '07

Full_Name: Gavin Henry Version: HEAD OS: FC8 - i386/x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry All, test050-syncrepl-multimaster only tested MMR with 2 instances of slapd. I extended the test case to use 3 instances. 3rd kept crashing. Howard has fixed in HEAD. Thanks, Gavin.

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by hyc＠symas.com 20 Nov '07

20 Nov '07

Dan.Oscarsson(a)tietoenator.com wrote: > If this looks correct to you, what code should I add to fix it? > It would be better if one of you who knows the code better than me could > do that. I can test and see if it works. > > I hope this is the only place in cache handling of an entries children, > though maybe someone with better knowledge on the code can identify > others. > > Hope this is the bug as I have used many days to trace it down and need > to do some normal work for my company. Thanks for your investigation; this explanation makes sense. You can test this simply by disabling the statement in bdb_cache_modrdn() which sets the NO_KIDS flags: Index: cache.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v retrieving revision 1.157 diff -u -r1.157 cache.c --- cache.c 12 Nov 2007 10:41:45 -0000 1.157 +++ cache.c 20 Nov 2007 15:09:29 -0000 @@ -1148,8 +1148,10 @@ free( ei->bei_nrdn.bv_val ); ber_dupbv( &ei->bei_nrdn, nrdn ); +#if 0 if ( !pei->bei_kids ) pei->bei_state |= CACHE_ENTRY_NO_KIDS | CACHE_ENTRY_NO_GRANDKIDS; +#endif #ifdef BDB_HIER free( ei->bei_rdn.bv_val ); Please try that and report your results. I don't think this is the best fix, but if it helps your test then we can refine it from there. -- -- Howard Chu Chief Architect, 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#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 20 Nov '07

20 Nov '07

mån 2007-11-12 klockan 15:15 -0800 skrev Quanah Gibson-Mount: > --On Monday, November 12, 2007 7:02 AM +0000 hyc(a)symas.com wrote: > > > > This isn't a lot of information to go on. If you can create a test > > program that shows the problem occurring, using dummy data, that would > > help. -- > > Also, Just some general data on what it is you are doing that is a bit more > explanative. I have now done several days of testing and think I have tracked what is wrong. All my tests have been done in 2.3.38. What my program going to do is: move one person from one branch to an other one. It does the following (in a simplified way): 1) search for the person entry using base o=xxx and filter uid=yyyy 2) does a modrdn from cn=qqq+uid=yyy,a=aaaa,b=bbbb,c=cccc,o=xxx to cn=qqq+uid=yyy,d=dddd,e=eeee,c=cccc,o=xxx I do this now on a newly started ldap server (that is cache have not been filled). This is a special case that I found triggered what is probably the bug I got previously but then the server may have been running for a long time. My analysis from all my debug prints indicate that: during 1) above the person entry is located and hdb_cache_find_parent is called which calls hdb_dn2id_parent to find the way to the root. From what I can see this constructs cache entries with one kid entry in bei_kids. It does not load all kids of each entry found along the path to root. Next in 2) modrdn is called and bdb_cache_modrdn. This removes the person entry from the a=aaaa entry. As the a=aaaa entry was cached during 1) with just setting one child instead of loading all from disk, that entry now has no children (bei_kids is NULL) so the state is set to CACHE_ENTRY_NO_KIDS. If I after this does a search with base c=cccc,o=xxx the hdb_dn2idl routine will not find all entries as the cached entry of a=aaaa,b=bbbb,c=cccc,o=xxx in hdb_dn2idl_internal has state CACHE_ENTRY_NO_KIDS and is ignored. If modrdn is step 2) before deleting the entry from its parents list of kids, had loaded all kids from disk, is should have worked. So the problem is, it my analysis is correct, is that sometimes cache entries are created which have not loaded the children from disk and then an other cache routine change the number of children in the cache without first loading the correct number of children from disk. If this looks correct to you, what code should I add to fix it? It would be better if one of you who knows the code better than me could do that. I can test and see if it works. I hope this is the only place in cache handling of an entries children, though maybe someone with better knowledge on the code can identify others. Hope this is the bug as I have used many days to trace it down and need to do some normal work for my company. Regards, Dan -- Dan Oscarsson TietoEnator Email: Dan.Oscarsson(a)tietoenator.com Box 85 201 20 Malmo, Sweden

1 0

Re: (ITS#5235) ppolicy leads to segfault
by ando＠sys-net.it 19 Nov '07

19 Nov '07

Dieter Kluenter wrote: > | #0 0xb7ac6139 in free () from /lib/libc.so.6 > | #1 0xb7f2028a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 > | #2 0x0809b1f2 in ch_free (ptr=0x2009) at ch_malloc.c:139 > | #3 0xb775358c in ppolicy_restrict (op=0xa2253d54, rs=0xa2254148) > | at ppolicy.c:1245 > | #4 0x080f0c5a in overlay_op_walk (op=0xa2253d54, rs=0xa2254148, > | which=op_search, oi=0x829d5d8, on=0x82a1190) at backover.c:642 > | #5 0x080f0e91 in over_op_func (op=0xa2253d54, rs=0xa2254148, which=op_search) > | at backover.c:704 > | #6 0x080f0f15 in over_op_search (op=0xa2253d54, rs=0xa2254148) > | at backover.c:726 > | #7 0xb773f893 in dds_expire (ctx=0xa2254238, di=0x82a4898) at dds.c:181 > | #8 0xb773fe4f in dds_expire_fn (ctx=0xa2254238, arg=0x829cc48) at dds.c:260 > | #9 0xb7f334d2 in ldap_int_thread_pool_wrapper (xpool=0x82507b0) at tpool.c:625 > | #10 0xb7d4f192 in start_thread () from /lib/libpthread.so.0 > | #11 0xb7b2102e in clone () from /lib/libc.so.6 > `---- > > ,----[ frame ] > | (gdb) frame 3 > | #3 0xb775358c in ppolicy_restrict (op=0xa2253d54, rs=0xa2254148) > | at ppolicy.c:1245 > | 1245 ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val ); I assume op->o_conn->c_conn == -1 here, since this is an internal operation. As such, it shouldn't affect slapo-ppolicy(5). 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5237) Possible documentation error in admin guide
by hyc＠symas.com 18 Nov '07

18 Nov '07

kara(a)karamcnair.com wrote: > Full_Name: Kara McNair > Version: 2.3.27 > OS: OS 10.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.80.228.143) > > > Hi there, > > I'm reading through your admin guide & on page: > http://www.openldap.org/doc/admin24/slapdconfig.html > the last line of section 6.3.2 looks to me like it might have an error in it? > > The text says: > "Some factors may not be appropriate in all environments (or any). For example, > the domain factor relies on IP to domain name lookups. As these can easily > spoofed, the domain factor should _*not*_ be avoided." > > The way it's phrased, I would have expected the final sentence to read: > "As these can easily spoofed, the domain factor should be avoided." > > (the 'not' appears to be at odds with the 'avoided') > > (also, I think there's a 'be' missing between 'easily' and 'spoofed'). > > Thanks very much for your excellent software and very thorough and helpful > documentation! Thanks for the bug report, this is now fixed in CVS. Note that you reported version 2.3.27 on your bug report; it's not a good idea to use docs that don't match the version of software you're using. I suggest you upgrade to 2.3.39 at least and use the docs bundled in that release, or switch to 2.4.6. -- -- Howard Chu Chief Architect, 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#5235) ppolicy leads to segfault
by hyc＠symas.com 18 Nov '07

18 Nov '07

ando(a)sys-net.it wrote: > dieter(a)dkluenter.de wrote: > >> (gdb) bt >> #0 0xb7a67139 in free () from /lib/libc.so.6 >> #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 >> #2 0x0808f556 in ch_free () >> #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) >> at ppolicy.c:1245 > > I suspect this free occurs an internal operation initiated with > connection_fake_init(); can you check, from the core, if the value of > op->o_conn->c_conn_idx is -1? If that's the real problem, the better fix would be just to make ppolicy ignore fake connections. Certainly internal operations can never be restricted. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5237) Possible documentation error in admin guide
by kara＠karamcnair.com 18 Nov '07

18 Nov '07

Full_Name: Kara McNair Version: 2.3.27 OS: OS 10.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.80.228.143) Hi there, I'm reading through your admin guide & on page: http://www.openldap.org/doc/admin24/slapdconfig.html the last line of section 6.3.2 looks to me like it might have an error in it? The text says: "Some factors may not be appropriate in all environments (or any). For example, the domain factor relies on IP to domain name lookups. As these can easily spoofed, the domain factor should _*not*_ be avoided." The way it's phrased, I would have expected the final sentence to read: "As these can easily spoofed, the domain factor should be avoided." (the 'not' appears to be at odds with the 'avoided') (also, I think there's a 'be' missing between 'easily' and 'spoofed'). Thanks very much for your excellent software and very thorough and helpful documentation! Kara

1 0

Re: (ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 17 Nov '07

17 Nov '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > >> (gdb) bt >> #0 0xb7a67139 in free () from /lib/libc.so.6 >> #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 >> #2 0x0808f556 in ch_free () >> #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) >> at ppolicy.c:1245 > > I suspect this free occurs an internal operation initiated with > connection_fake_init(); can you check, from the core, if the value of > op->o_conn->c_conn_idx is -1? OK, now again frome the beginning: ,----[ backtrace ] | (gdb) bt | #0 0xb7ac6139 in free () from /lib/libc.so.6 | #1 0xb7f2028a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 | #2 0x0809b1f2 in ch_free (ptr=0x2009) at ch_malloc.c:139 | #3 0xb775358c in ppolicy_restrict (op=0xa2253d54, rs=0xa2254148) | at ppolicy.c:1245 | #4 0x080f0c5a in overlay_op_walk (op=0xa2253d54, rs=0xa2254148, | which=op_search, oi=0x829d5d8, on=0x82a1190) at backover.c:642 | #5 0x080f0e91 in over_op_func (op=0xa2253d54, rs=0xa2254148, which=op_search) | at backover.c:704 | #6 0x080f0f15 in over_op_search (op=0xa2253d54, rs=0xa2254148) | at backover.c:726 | #7 0xb773f893 in dds_expire (ctx=0xa2254238, di=0x82a4898) at dds.c:181 | #8 0xb773fe4f in dds_expire_fn (ctx=0xa2254238, arg=0x829cc48) at dds.c:260 | #9 0xb7f334d2 in ldap_int_thread_pool_wrapper (xpool=0x82507b0) at tpool.c:625 | #10 0xb7d4f192 in start_thread () from /lib/libpthread.so.0 | #11 0xb7b2102e in clone () from /lib/libc.so.6 `---- ,----[ frame ] | (gdb) frame 3 | #3 0xb775358c in ppolicy_restrict (op=0xa2253d54, rs=0xa2254148) | at ppolicy.c:1245 | 1245 ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val ); | (gdb) `---- This shows three memory regions ,----[ memory values ] | (gdb) x/c 0xb775358c | 0xb775358c <ppolicy_restrict+108>: -117 '\213' | (gdb) | | (gdb) x/c 0xa2253d54 | 0xa2253d54: 40 '(' | (gdb) | | (gdb) x/c 0xa2254148 | 0xa2254148: 0 '\0' | (gdb) `---- I hope this is more informative. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 17 Nov '07

17 Nov '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > >> (gdb) bt >> #0 0xb7a67139 in free () from /lib/libc.so.6 >> #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 >> #2 0x0808f556 in ch_free () >> #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) >> at ppolicy.c:1245 > > I suspect this free occurs an internal operation initiated with > connection_fake_init(); can you check, from the core, if the value of > op->o_conn->c_conn_idx is -1? Sorry, I'm a bit stupid. (gdb) frame 3 #3 0xb76e758c in ppolicy_restrict (op=0xa09e4d54, rs=0xa09e5148) at ppolicy.c:1245 1245 ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val ); (gdb) -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 17 Nov '07

17 Nov '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > >> (gdb) bt >> #0 0xb7a67139 in free () from /lib/libc.so.6 >> #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 >> #2 0x0808f556 in ch_free () >> #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) >> at ppolicy.c:1245 > > I suspect this free occurs an internal operation initiated with > connection_fake_init(); can you check, from the core, if the value of > op->o_conn->c_conn_idx is -1? sorry :-( (gdb) gcore *** buffer overflow detected ***: gdb terminated ======= Backtrace: ========= -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5235) ppolicy leads to segfault
by ando＠sys-net.it 17 Nov '07

17 Nov '07

dieter(a)dkluenter.de wrote: > (gdb) bt > #0 0xb7a67139 in free () from /lib/libc.so.6 > #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 > #2 0x0808f556 in ch_free () > #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) > at ppolicy.c:1245 I suspect this free occurs an internal operation initiated with connection_fake_init(); can you check, from the core, if the value of op->o_conn->c_conn_idx is -1? 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: Documentation should indicate that slurpd is deprecated (ITS#5196)
by ghenry＠OpenLDAP.org 16 Nov '07

16 Nov '07

marg(a)rz.tu-clausthal.de wrote: > Hello, > > fig. 3.3 in > > http://www.openldap.org/doc/admin24/config.html > > mentions "slurpd", while the text was updated to reflect syncrepl. > > bye > Christian Thanks, I haven't had time to update the pics yet. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5236) core.ldif differs from core.schema
by ando＠sys-net.it 16 Nov '07

16 Nov '07

hyc(a)symas.com wrote: > dieter(a)dkluenter.de wrote: > Seems someone updated core.schema for RFC4519 but didn't update core.ldif. Was me, sorry. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5236) core.ldif differs from core.schema
by hyc＠symas.com 16 Nov '07

16 Nov '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.190.40) > > > core.ldif > > olcAttributeTypes: ( 2.5.4.6 NAME ( 'c' 'countryName' ) > DESC 'RFC2256: ISO-3166 country 2-letter code' > SUP name SINGLE-VALUE ) > > core.schema > attributetype ( 2.5.4.6 NAME 'c' > DESC 'RFC2256: ISO-3166 country 2-letter code' > SUP name > SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 > SINGLE-VALUE ) > > As far as I understand, core.schema is correct here. Seems someone updated core.schema for RFC4519 but didn't update core.ldif. I'm puzzled why RFC4519 drops the 'countryName' alias for this type from the RFC2256 definition. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5236) core.ldif differs from core.schema
by dieter＠dkluenter.de 16 Nov '07

16 Nov '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.190.40) core.ldif olcAttributeTypes: ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SINGLE-VALUE ) core.schema attributetype ( 2.5.4.6 NAME 'c' DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) As far as I understand, core.schema is correct here. -Dieter

1 0

Re: Documentation should indicate that slurpd is deprecated (ITS#5196)
by marg＠rz.tu-clausthal.de 16 Nov '07

16 Nov '07

Hello, fig. 3.3 in http://www.openldap.org/doc/admin24/config.html mentions "slurpd", while the text was updated to reflect syncrepl. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

1 0

(ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 15 Nov '07

15 Nov '07

Full_Name: Dieter Kluenter Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.231.219) I am testing ppolicy overlay with HEAD. When starting slapd it segfaults with: .... ber_scanf fmt ({mm}) ber: ber_dump: buf=0xa015009c ptr=0xa01500bc end=0xa01500e5 len=41 0000: 00 27 04 14 65 6e 74 72 79 45 78 70 69 72 65 54 .'..entryExpireT 0010: 69 6d 65 73 74 61 6d 70 04 0f 32 30 30 37 31 31 imestamp..200711 0020: 31 35 32 31 31 31 32 33 5a 15211123Z end get_filter 0 end get_filter_list end get_filter 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xa0a51b90 (LWP 5703)] 0xb7a67139 in free () from /lib/libc.so.6 this is gdb backtrace (gdb) bt #0 0xb7a67139 in free () from /lib/libc.so.6 #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 #2 0x0808f556 in ch_free () #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) at ppolicy.c:1245 #4 0x080d564e in overlay_op_walk () #5 0x080d5bee in ?? () #6 0xa0a50d54 in ?? () #7 0xa0a51148 in ?? () #8 0x00000002 in ?? () #9 0x082695b0 in ?? () #10 0x08270c50 in ?? () #11 0xa0a50be8 in ?? () #12 0xa0a50cec in ?? () #13 0xa0a50ce8 in ?? () #14 0x00000002 in ?? () #15 0xa0a51148 in ?? () #16 0x08270c50 in ?? () #17 0x000003f2 in ?? () #18 0x00000000 in ?? () -Dieter

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 15 Nov '07

15 Nov '07

Tested in HEAD again, on same machine with same cmd: for i in `seq 1 100`; do ./run test020 >> test_results.log; done; and grepped the log file for "Error" and -i "succeed". Results: 100 Passes 0 Fails Looks good to me. Gavin. -- 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/

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org 15 Nov '07

15 Nov '07

Make that: http://www.perl.me.uk/testrun008.tar.gz ftp.openldap.org incoming kept failing.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs