openldap-bugs April 2009

openldap-bugs@openldap.org

49 participants
141 discussions

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > > Why do you have so many threads configured? How many cpu's do you have?? > > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > > > > > I have an application which generates heavy load in slapd (many > > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > > BDB databases are situated on separate disk and BDB logs are on the other > > disk. But slapd performance (I mean time to answer) still cuts > > down during large disk IO periods 'cause these disks are used by other > > applications at the same time. And so I have increased number of threads > > from the defaults threads=32 up to 64, just to save some time for my > > application which requires not more then 30 ms for one search to > > complete. > > Just to be sure I have tried the default settings for threads and it's > > behaviour didn't changed - slapd heap memory just continuously grows (I > > have seen through pmap)... > > Also I have tried libtcmalloc which is usually recommended and solaris > > built in' libmtmalloc, but it didn't helped. > > > > Please copy replies to the bug tracker if you expect help. > > I will note that every thread consumes a large chunk of memory. I will also > note that the default is 16 threads, not 32. I will also note, that as far > as read operations are concerned, usually *fewer* threads is faster, not > more. >You appear to have quite an excessive amount of threads configured. > I have mentioned that using the defaults didn't helped. Probably I was mistaken about the default number of threads - but if keywords "threads" is missing in config it simply means the defaults, right? May be threads should be lower then the defaults (e.g. 6 or 8)?

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by Quanah Gibson-Mount 17 Apr '09

17 Apr '09

--On Friday, April 17, 2009 10:25 PM +0300 sscdvp(a)gmail.com wrote: > Why do you have so many threads configured? How many cpu's do you have?? > > > >> I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from >> Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many > ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). > BDB databases are situated on separate disk and BDB logs are on the other > disk. But slapd performance (I mean time to answer) still cuts > down during large disk IO periods 'cause these disks are used by other > applications at the same time. And so I have increased number of threads > from the defaults threads=32 up to 64, just to save some time for my > application which requires not more then 30 ms for one search to > complete. > Just to be sure I have tried the default settings for threads and it's > behaviour didn't changed - slapd heap memory just continuously grows (I > have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris > built in' libmtmalloc, but it didn't helped. Please copy replies to the bug tracker if you expect help. I will note that every thread consumes a large chunk of memory. I will also note that the default is 16 threads, not 32. I will also note, that as far as read operations are concerned, usually *fewer* threads is faster, not more. You appear to have quite an excessive amount of threads configured. Others will have to continue the conversation on what you're seeing growth wise. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by sscdvp＠gmail.com 17 Apr '09

17 Apr '09

2009/4/17, sscdvp(a)gmail.com <sscdvp(a)gmail.com>: > > > > > > > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > > According to ITS#5860 slapd should not allocate more memory than it was > > > specified. In fact I have the same behaviour as it was with previous > > > > > > version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for > > > set_cachesize 300 MB). But slapd process continuosly grows in memory until > > > 32-bit limit then crashes due to unavalable memory resources. I need to > > > > > > mention bdb database size is less then 1 GB. > > > After restart it rapidly consumes 1.5 GB RSS in few minutes and then it > > > grows beyond the limit during 24 hours. The more queries are processing > > > the more memory it eats. > > > > > > I am using this database for logging which size grows. > > > The question is: is it possible to use 32-bit openldap with relatively > > > large database sizes that override 32-bit per-process memory space? > > > > > > My slapd.conf contains: > > > > > > > > > threads 64 > > > > > > > Why do you have so many threads configured? How many cpu's do you have?? > > > > I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from > > Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. > > I have an application which generates heavy load in slapd (many ldap_search'es and very very many ldap_add, ldap_modify, ldap_delete). BDB databases are situated on separate disk and BDB logs are on the other disk. But slapd performance (I mean time to answer) still cuts down during large disk IO periods 'cause these disks are used by other applications at the same time. And so I have increased number of threads from the defaults threads=32 up to 64, just to save some time for my application which requires not more then 30 ms for one search to complete. > Just to be sure I have tried the default settings for threads and it's behaviour didn't changed - slapd heap memory just continuously grows (I have seen through pmap)... > Also I have tried libtcmalloc which is usually recommended and solaris built in' libmtmalloc, but it didn't helped.

1 0

Re: (ITS#6058) slapcat aborts on a double free
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

luca(a)openldap.org writes: > Slapcat on a slapd instance using rwm overlay, aborts with: > *** glibc detected *** free(): invalid pointer: 0x09ed06e3 *** It's an invalid free() of (static EntryHeader eh).e_bv.bv_val at: ch_free (ch_malloc.c:139) hdb_tool_entry_close (back-hdb/tools.c:164) slapcat (slapcat.c:135) main (main.c:636) already freed (as (Entry *e)->e_bv.bv_val) at: ch_free (ch_malloc.c:139) entry_clean (entry.c:498) entry_free (entry.c:514) rwm_entry_release_rw (overlays/rwm.c:827) overlay_entry_release_ov (backover.c:421) over_entry_release_rw (backover.c:463) be_entry_release_rw (backend.c:867) slapcat (slapcat.c:117) main (main.c:636) I needed to prepend include servers/slapd/schema/core.schema to your config. -- Hallvard

1 0

Re: (ITS#5975) minor issue with slapd.conf manpage
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

eric(a)huss.org wrote: > There appears to be a couple slightly incorrect statements in the slapd.conf > manpage. It says that the argsfile and pidfile values are used "if started > without the debugging command line option". However, it doesn't appear to > make any difference whether or not you use the -d option with slapd. Fixed the doc in HEAD. Also the argsfile did not mention that the program name is written to argsfile as well as the options. -- Hallvard

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by h.b.furuseth＠usit.uio.no 17 Apr '09

17 Apr '09

rein(a)OpenLDAP.org writes: > I've had two cases where a delete operation was performed on the > master without being replicated to its consumers, which so far appear > to be cases of possible connection lost (abandon) race conditions. Not sure if this is the problem, but it is ugly: slapd/cancel.c sets o_abandon with op->o_conn->c_mutex locked, but waits to set o_cancel after it's unlocked. Looks like that can give slapd a chance to react to o_abandon before it "knows" that abandon is actually a cancel. > Do we need some sort of o_committed flag that can be used to prevent > o_abandon from being set or acted upon? Or handle o_abandon more like > o_cancel, i.e with multiple values, including "too late"? o_cancel is a wrapper around o_abandon, turning result code SLAPD_ABANDON into LDAP_TOO_LATE etc. However slap_send_ldap_result() and send_ldap_response() skip "if (op->o_callback) slap_response_play()" if o_abandon is set, and "send" SLAPD_ABANDON instead of the result code. Can that work right? The code looks like SLAPD_ABANDON ought to mean "nothing was done" right up till everything has had a chance to react the same way to an operation. -- Hallvard

1 0

Re: (ITS#6065) slapcat with sql (postgres) backend
by ando＠sys-net.it 17 Apr '09

17 Apr '09

frederic.bouy(a)gmail.com wrote: > Full_Name: Frederic Bouy > Version: 2.4.12 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.255.106.203) > > > When running the following command: > slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 > I get this error message: > <==backsql_load_schema_map() > ==>backsql_free_db_conn() > ==>backsql_close_db_handle(0x8290c18) > <==backsql_close_db_handle(0x8290c18) > <==backsql_free_db_conn() > <==backsql_db_open(): test succeeded, schema map loaded > slapcat: database doesn't support necessary operations. > > ldapsearch is successfull. > > Do you have any clue on how to solve this issue? The message should be pretty self explanatory. A solution consists in implementing the missing support. 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#6065) slapcat with sql (postgres) backend
by frederic.bouy＠gmail.com 17 Apr '09

17 Apr '09

Full_Name: Frederic Bouy Version: 2.4.12 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.255.106.203) When running the following command: slapcat -l /tmp/lnp.ldif -f /usr/local/openldap/etc/openldap/slapd.conf -d 1 I get this error message: <==backsql_load_schema_map() ==>backsql_free_db_conn() ==>backsql_close_db_handle(0x8290c18) <==backsql_close_db_handle(0x8290c18) <==backsql_free_db_conn() <==backsql_db_open(): test succeeded, schema map loaded slapcat: database doesn't support necessary operations. ldapsearch is successfull. Do you have any clue on how to solve this issue? Thanks for your help.

1 0

Antwort: Re: (ITS#5837) slapd pthread_kill Core Dump AIX
by howard.allison＠pva.sozvers.at 17 Apr '09

17 Apr '09

--0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: multipart/alternative; Boundary="1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841" --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable This is a full Backtrace - about 200 MB of Real Memory available(from 2= GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpthread.a(shr_xpg5.o= ) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread.a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o) No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o) No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a(shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_malloc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at search.c:1013 bdb =3D (struct bdb_info *) 0x20188b98 ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4, scopes=3D0x26379= bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98 rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result =3D 640653996, f= _un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un_ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9aac}, f_next =3D 0= x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_result =3D 640654008, = f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_un_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9ab8}, f_next =3D 0= x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_result =3D 640653972, = f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_un_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a94}, f_next =3D 0= x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 0, f_un_desc = =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra =3D 0x0, f_un_complex =3D = 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D {bv_len =3D 8,= bv_val =3D 0x102dbf2c "r\ef\erral"}} sf =3D {f_choice =3D 0, f_un =3D {f_un_result =3D 641440756, f_= un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9bf4}, f_next =3D 0= x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D {bv_len =3D 0, b= v_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x263ba824) at sear= ch.c:578 bdb =3D (struct bdb_info *) 0x20188b98 id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>} scopes =3D {0 <repeats 63759 times>, 641435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 641434656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 641434672, 0, 0, 0, 32,= 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 2567258180, 3490905504, 0= , 641434768, 4030840384, 4112, 0, 4030805596, 4030426872, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 3490902496, 0, 6414348= 00, 4030840384, 58, 22528, 0, 144, 0, 269721729, 269721729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 641434880, 4030840384= , 3490883944, 0, 641434896, 4030840384, 3490889600, 641435752, 641434896,= 4030840384, 3491274292, 0, 0, 641437345, 641437340, 1, 0, 1, 40304311= 12, 4030431112, 641434960, 0, 3490885628, 641435752, 641435008, 4030840384,= 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992, 0, 0, 641435752= , 641435008, 4031927728, 3491274292, 608035800, 641435072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0, 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3491266240, 0= , 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14, 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times>, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 678360812, bv_val = =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"}, e_attrs =3D= 0x3, e_ocflags =3D 641440736, e_bv =3D {bv_len =3D 641440832, bv_val =3D 0xf= 041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc= =3Dsozv \ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 77770, mode =3D DB_LO= CK_READ} opinfo =3D (struct bdb_op_info *) 0x0 ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backover.c:646 func =3D (BI_op_bind **) 0x200012b4 rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 on =3D (slap_overinst *) 0x20189e78 be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\001\000\000\001\001\00= 0 \001", '\0' <repeats 17 times>, "\001", be_flags =3D 2312, be_restricto= ps =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D 0= , sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0, sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_simple_bind =3D 0}= , be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28, be_schemadn =3D {b= v_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, bv_val =3D 0x0}, b= e_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootndn =3D {bv_len =3D 34, bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva,dc=3Dsozv\ers,dc=3Dat= "}, be_rootpw =3D {bv_len =3D 5, bv_val =3D 0x20187138 "start"}, be_max_deref_depth =3D= 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D 0, lms_s_soft =3D= -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_pr =3D 0, lms_s_pr_hide= =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D 0, bv_val =3D= 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20356508, be_pcl_mu= tex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, be_pb =3D 0x0, be_= cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_next =3D {stqe_next =3D 0x201= 92308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x2001e51c: 0x100d553= c <over_back_response>, sc_cleanup =3D @0x0: 0x1, sc_private =3D 0x20189d= 68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x263ba824) at searc= h.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff "dc=3Dpva,dc=3Ds= ozv \ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c out of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba95c, arg_v=3D0x243= de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, sr_msgid =3D 0, s= r_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, = sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0= x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0= , r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D 0, r= _v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 #15 0x1006c848 in connection_read_thread (ctx=3D0x263ba95c, argv=3D0x20= ) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1, arg =3D 0x0, ct= x =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x200c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8 work_list =3D (ldap_int_tpool_plist_t *) 0x200c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_key =3D 0x2001e2ac,= ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x1006b814 <conn_counter_destroy>= }, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, ltk_free =3D @0x2= 001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk_key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D 0x51eadec0,= ltk_free =3D @0x200201fc: 0x1020f550 <bdb_locker_id_free>}, {ltk_= key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0: 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0 i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c "" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpthread.a(shr_xpg5.= o) No symbol table info available. Mit freundlichen Gr=FC=DFen Howard ALLISON Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: howard.allison(a)pva.sozvers.at Internet: www.pensionsversicherung.at -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the individuality or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure. If you are not the intended recipient you are notified that any dissemination, distribution, use or copying of this communication is strictly prohibited. If you received this message in error, please immediately destroy this message. --------------------------= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable <html><body> This is a full Backtrace - about 200 MB of Real Mem= ory available(from 2 GB), and 2 GB of swap available. Thanks #0 0xd04a7560 in pthread_kill () from /usr/lib/libpth= read.a(shr_xpg5.o) No symbol table info available. #1 0xd04a69cc in _p_raise () from /usr/lib/libpthread= .a(shr_xpg5.o) No symbol table info available. #2 0xd01367e4 in raise () from /usr/lib/libs.a(shr.o)= No symbol table info available. #3 0xd01a9028 in abort () from /usr/lib/libs.a(shr.o)= No symbol table info available. #4 0xd0164878 in __assert_c99 () from /usr/lib/libs.a= (shr.o) No symbol table info available. #5 0x1000cbe4 in ch_malloc (size=3D8388608) at ch_mal= loc.c:57 new =3D (void *) 0x0 #6 0x1022a80c in search_stack (op=3D0x243de2d8) at se= arch.c:1013 bdb =3D (struct bdb_info *) 0x20188b98<= br> ret =3D (void *) 0x0 #7 0x1022ac0c in search_candidates (op=3D0x243de2d8, = rs=3D0x263ba824, e=3D0x263b9bc4, locker=3D0x51eadec0, ids=3D0x262f9bc4,= scopes=3D0x26379bc4) at search.c:1099 bdb =3D (struct bdb_info *) 0x20188b98<= br> rc =3D 640653952 depth =3D 3 f =3D {f_choice =3D 160, f_un =3D {f_un_result= =3D 640653996, f_un_desc =3D 0x262f9aac, f_un_ava =3D 0x262f9aac, f_un= _ssa =3D 0x262f9aac, f_un_mra =3D 0x262f9aac, f_un_complex =3D 0x262f9a= ac}, f_next =3D 0x0} rf =3D {f_choice =3D 163, f_un =3D {f_un_resul= t =3D 640654008, f_un_desc =3D 0x262f9ab8, f_un_ava =3D 0x262f9ab8, f_u= n_ssa =3D 0x262f9ab8, f_un_mra =3D 0x262f9ab8, f_un_complex =3D 0x262f9a= b8}, f_next =3D 0x286ef7dc} xf =3D {f_choice =3D 161, f_un =3D {f_un_resul= t =3D 640653972, f_un_desc =3D 0x262f9a94, f_un_ava =3D 0x262f9a94, f_u= n_ssa =3D 0x262f9a94, f_un_mra =3D 0x262f9a94, f_un_complex =3D 0x262f9a= 94}, f_next =3D 0x0} nf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 0, f_un_desc =3D 0x0, f_un_ava =3D 0x0, f_un_ssa =3D 0x0, f_un_mra = =3D 0x0, f_un_complex =3D 0x0}, f_next =3D 0x262f9aa0} stack =3D (ID *) 0x1020cc58 aa_ref =3D {aa_desc =3D 0x200c0268, aa_value =3D= {bv_len =3D 8, bv_val =3D 0x102dbf2c "r\ef\erral"}}<b= r> sf =3D {f_choice =3D 0, f_un =3D {f_un_result = =3D 641440756, f_un_desc =3D 0x263b9bf4, f_un_ava =3D 0x263b9bf4, f_un_= ssa =3D 0x263b9bf4, f_un_mra =3D 0x263b9bf4, f_un_complex =3D 0x263b9b= f4}, f_next =3D 0x262f9ad0} aa_subentry =3D {aa_desc =3D 0x0, aa_value =3D= {bv_len =3D 0, bv_val =3D 0x0}} bv_ref =3D {bv_len =3D 8, bv_val =3D 0x102dbf2= c "r\ef\erral"} #8 0x10228ee4 in bdb_search (op=3D0x243de2d8, rs=3D0x= 263ba824) at search.c:578 bdb =3D (struct bdb_info *) 0x20188b98<= br> id =3D 0 cursor =3D 0 lastid =3D 4294967295 candidates =3D {0 <repeats 131072 times>= } scopes =3D {0 <repeats 63759 times>, 641= 435536, 0, 0, 0, 0, 4030840384, 0 <repeats 11 times>, 641435684, = 0 <repeats 206 times>, 641434560, 0 <repeats 11 times>, 641434656, 0, 0, 0, 6414= 34656, 4030840384, 3490904144, 0, 0, 4030840384, 0, 0, 0, 0, 0, 0, 6414= 34672, 0, 0, 0, 32, 58, 22528, 0, 0, 11, 58, 4030431112, 641434720, 25672581= 80, 3490905504, 0, 641434768, 4030840384, 4112, 0, 4030805596, 40304268= 72, 608034984, 959840256, 110, 608035812, 0, 0, 641434800, 0, 34909= 02496, 0, 641434800, 4030840384, 58, 22528, 0, 144, 0, 269721729, 26972= 1729, 4030854004, 3490917464, 0, 641434880, 4112, 58, 4030431112, 6414= 34880, 4030840384, 3490883944, 0, 641434896, 4030840384, 3490889600, 64= 1435752, 641434896, 4030840384, 3491274292, 0, 0, 641437345, 641437340, = 1, 0, 1, 4030431112, 4030431112, 641434960, 0, 3490885628, 641435752, 6= 41435008, 4030840384, 3491268044, 0, 641434976, 4030840384, 0, 0, 641434992= , 0, 0, 641435752, 641435008, 4031927728, 3491274292, 608035800, 641435= 072, 297, 3490878276, 0, 641435072, 4030840384, 3490889836, 0,= 641435072, 4030840384, 3490889600, 641435752, 641435648, 4030840384, 3= 491266240, 0, 0, 4030840384, 0, 14, 32, 608035800, 0, 0, 0, 0, 14, 14= , 641435168, 0, 3490878896, 0, 0, 4030840384, 0 <repeats 11 times&gt= ;, 608035800, 1, 0, 641437088...} e =3D (Entry *) 0x0 base =3D {e_id =3D 1, e_name =3D {bv_len =3D 6= 78360812, bv_val =3D 0x23a301e0 ""}, e_nname =3D {bv_len =3D = 23, bv_val =3D 0x243e94e8 "dc=3Dpva,dc=3Dsozv\ers= ,dc=3Dat"}, e_attrs =3D 0x3, e_ocflags =3D 641440736, e_bv =3D {bv= _len =3D 641440832, bv_val =3D 0xf041be40 ""}, e_private =3D 0x203a0f78} e_root =3D (Entry *) 0x2035880c matched =3D (Entry *) 0x0 ei =3D (EntryInfo *) 0x203a0f78 attrs =3D (AttributeName *) 0x0 realbase =3D {bv_len =3D 23, bv_val =3D 0x243e= 94e8 "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} mask =3D 5119 stoptime =3D 1239955337 manageDSAit =3D 0 tentries =3D 0 nentries =3D 0 idflag =3D 0 locker =3D 0x51eadec0 lock =3D {off =3D 0, ndx =3D 412, gen =3D 7777= 0, mode =3D DB_LOCK_READ} opinfo =3D (struct bdb_op_info *) 0x0<b= r> ltid =3D (DB_TXN *) 0x0 oex =3D (OpExtra *) 0x0 stub =3D {bv_len =3D 4030851424, bv_val =3D 0x= 0} #9 0x100d66dc in overlay_op_walk (op=3D0x243de2d8, rs= =3D0x263ba824, which=3Dop_search, oi=3D0x20189d68, on=3D0x0) at backove= r.c:646 func =3D (BI_op_bind **) 0x200012b4 = rc =3D 32768 sc_next =3D (slap_callback *) 0x0 #10 0x100d691c in over_op_func (op=3D0x243de2d8, rs=3D= 0x263ba824, which=3Dop_search) at backover.c:698 oi =3D (slap_overinfo *) 0x20189d68 = on =3D (slap_overinst *) 0x20189e78 = be =3D (BackendDB *) 0x20187f68 db =3D {bd_info =3D 0x20001288, bd_self =3D 0x= 20187f68, be_ctrls =3D "\000\001\001\001\000\001\000\000\= 001\000\000\001\001\000\001", '\0' <repeats 17 times>, &quot= ;\001", be_flags =3D 2312, be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, ss= s_transport =3D 0, sss_tls =3D 0, sss_sasl =3D 0, sss_update_ssf =3D 0,= sss_update_transport =3D 0, sss_update_tls =3D 0, sss_update_sasl =3D 0, sss_s= imple_bind =3D 0}, be_suffix =3D 0x20183b08, be_nsuffix =3D 0x20189a28,= be_schemadn =3D {bv_len =3D 0, bv_val =3D 0x0}, be_schemandn =3D {bv_len =3D 0, b= v_val =3D 0x0}, be_rootdn =3D {bv_len =3D 34, bv_val =3D 0x20189ce8 "cn=3DManag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootndn =3D {bv_len =3D 34,<br= > bv_val =3D 0x20189d38 "cn=3Dmanag\er,dc=3Dpva= ,dc=3Dsozv\ers,dc=3Dat"}, be_rootpw =3D {bv_len =3D 5, bv_val =3D = 0x20187138 "start"}, be_max_deref_depth =3D 15, be_def_limit =3D {lms_t_soft =3D 3600, lms_t_hard =3D= 0, lms_s_soft =3D -1, lms_s_hard =3D 0, lms_s_unchecked =3D -1, lms_s_= pr =3D 0, lms_s_pr_hide =3D 0, lms_s_pr_total =3D 0}, be_limits =3D 0x0, be_acl =3D= 0x2016b768, be_dfltaccess =3D ACL_READ, be_update_ndn =3D {bv_len =3D = 0, bv_val =3D 0x0}, be_update_refs =3D 0x0, be_pending_csn_list =3D 0x20= 356508, be_pcl_mutex =3D {__mt_word =3D {0, 0, 0, 1, 0, 1373, 0, 5, 0, = 0, 0, 0, 0}}, be_pcl_mutexp =3D 0x20188034, be_syncinfo =3D 0x0, b= e_pb =3D 0x0, be_cf_ocs =3D 0x2001b2a8, be_private =3D 0x20188b98, be_n= ext =3D {stqe_next =3D 0x20192308}} cb =3D {sc_next =3D 0x0, sc_response =3D @0x20= 01e51c: 0x100d553c <over_back_response>, sc_cleanup =3D @0x0: 0x1= , sc_private =3D 0x20189d68} rc =3D 32768 #11 0x100d6a84 in over_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at backover.c:720 No locals. #12 0x100b3434 in fe_op_search (op=3D0x243de2d8, rs=3D= 0x263ba824) at search.c:366 bd =3D (BackendDB *) 0x20046498 entry =3D (Entry *) 0x1021638 #13 0x100b2b2c in do_search (op=3D0x243de2d8, rs=3D0x2= 63ba824) at search.c:217 base =3D {bv_len =3D 23, bv_val =3D 0x243e93ff= "dc=3Dpva,dc=3Dsozv\ers,dc=3Dat"} siz =3D 0 off =3D 0 i =3D 0 dummy =3D 0x5469746c <Address 0x5469746c ou= t of bounds> #14 0x1006c154 in connection_operation (ctx=3D0x263ba9= 5c, arg_v=3D0x243de2d8) at connection.c:1084 rc =3D 80 op =3D (Operation *) 0x243de2d8 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 0, = sr_msgid =3D 0, sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_r= ef =3D 0x0, sr_ctrls =3D 0x0, sr_un =3D { sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D= {r_rspoid =3D 0x0, r_rspdata =3D 0x0}, sru_search =3D {r_entry =3D 0x0= , r_attr_flags =3D 0, r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_= nentries =3D 0, r_v2ref =3D 0x0}}, sr_flags =3D 0} tag =3D 99 opidx =3D SLAP_OP_SEARCH conn =3D (Connection *) 0x201bd448 memctx =3D (void *) 0x243de6b8 memctx_null =3D (void *) 0x0 memsiz =3D 1048576 curelm =3D (struct Operation *) 0x1 = #15 0x1006c848 in connection_read_thread (ctx=3D0x263b= a95c, argv=3D0x20) at connection.c:1211 rc =3D 0 cri =3D {op =3D 0x243de2d8, func =3D @0x0: 0x1= , arg =3D 0x0, ctx =3D 0x263ba95c, nullop =3D 0} s =3D 32 #16 0xd26daf88 in ldap_int_thread_pool_wrapper (xpool=3D= 0x200c9588) at tpool.c:663 pool =3D (struct ldap_int_thread_pool_s *) 0x2= 00c9588 task =3D (ldap_int_thread_task_t *) 0x23e43ae8= work_list =3D (ldap_int_tpool_plist_t *) 0x200= c961c ctx =3D {ltu_id =3D 1286, ltu_key =3D {{ltk_ke= y =3D 0x2001e2ac, ltk_data =3D 0x243de5a8, ltk_free =3D @0x2001e2b8: 0x= 1006b814 <conn_counter_destroy>}, {ltk_key =3D 0x2001e048, ltk_data =3D 0x243de6b8, = ltk_free =3D @0x2001e054: 0x1000a1e4 <slap_sl_mem_destroy>}, {ltk= _key =3D 0x20020b20, ltk_data =3D 0x0, ltk_free =3D @0x20020b2c: 0x10= 009864 <slap_op_q_destroy>}, {ltk_key =3D 0x20356518, ltk_data =3D= 0x51eadec0, ltk_free =3D @0x200201fc: 0x1020f550 <bdb_loc= ker_id_free>}, {ltk_key =3D 0x0, ltk_data =3D 0x0, ltk_free =3D @0x0= : 0x1} <repeats 28 times>}} kctx =3D (ldap_int_thread_userctx_t *) 0x0</fo= nt> i =3D 32 keyslot =3D 171 hash =3D 171 ptr_ =3D (const unsigned char *) 0x263ba95c &q= uot;" i_ =3D 4 #17 0xd048fc50 in _pthread_body () from /usr/lib/libpt= hread.a(shr_xpg5.o) No symbol table info available. Mit freundlichen Gr=FC=DFen<= b> Howard ALLISON <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"95"><img src=3D"cid:1__=3D4EBBFF08DFA38= 8418f9e8a93d(a)pva.sozvers.at" width=3D"83" height=3D"52"></td><td width=3D= "237" valign=3D"middle">Pensionsversicherungsanstalt Rechenzentrumsbetrieb A-1021 Wien, Friedrich-Hillegeist-Stra=DFe 1 E-Mail..: <a href=3D"mailto:howard.allison@pva.sozvers.at"><f= ont size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">howard.allison@= pva.sozvers.at</a><b= r> Internet: <a href=3D"http://www.pensionsversicherung.at/"><fo= nt size=3D"2" color=3D"#0000FF" face=3D"MS Sans Serif">www.pensionsvers= icherung.at</a></td></tr> </table> -------------------------- VERTRAULICHKEIT: Diese Nachricht ist ausschlie=DFlich f=FCr denjenigen = bestimmt, an den sie adressiert ist und kann vertrauliche Informationen enthalten. F= alls Sie nicht der Empf=E4nger dieser Nachricht sind, weisen wir Sie darauf hin, dass = die unberechtigte Weitergabe oder Verwendung sowie das unberechtigte Vertei= len oder Kopieren dieser Nachricht strikt untersagt sind. Falls Sie diese Nachri= cht irrt=FCmlich erhalten haben, vernichten Sie sie bitte sofort. CONFIDENTIALITY: This message is intended only for the use of the indiv= iduality or entity to which it is addressed and may contain information that is pri= vileged, confidential and exempt from disclosure. If you are not the intended re= cipient you are notified that any dissemination, distribution, use or copying of this c= ommunication is strictly prohibited. If you received this message in error, please imme= diately destroy this message. -------------------------- </body></html>= --1__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841-- --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841 Content-type: image/gif; name="18476766.gif" Content-Disposition: inline; filename="18476766.gif" Content-ID: <1__=4EBBFF08DFA388418f9e8a93d(a)pva.sozvers.at> Content-transfer-encoding: base64 R0lGODlhUwA0APcAAA4Rm9DR2jw/qpaYw3Z4sx4hoLy9zldZsIGDtTEzpbGyztbe3lBSr6ipyY+R vDg7p2xursnL1UZJqhgaoSosoEFDpsTF1dLT2hganp+iwIaIwmNmqyEpnGxvtnt8vbe40sHC0aap z1VXsklLpoeJuxwfn46QxZmZzF1fsdHS2WxuuTQ3piAjoSotpL6/09zd3kxPrRQXnVVYpmdptoqN vczMzKutzj0/p7i60nFztVRXrHp7tJqdwKqrxlpdskJFrJKUvn+AumJktdfY3LW2zYKFvZKUxqSl xr3F1khLrSQopM3O1igrpGpstpydxNbW1v4BAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AADYLuB3EgMwABIBAACV8AAAOQA8AAAAAACeAgAAAQAAAIhkWAAgwBUAqAZWAAIAAAC88hIA2Vi0 d9UHAYXk8hIAAgAAACj0EgAc8xIAotfhdxIDMAASAQAAlfAAADkAPAABAAAAEgEAAJXwAAASAzAA SLkVANi1FQAgACAAAAAVACAAIAAAABUARgBlAHIAdABpAGcAAAASAAAAAAD8iOd3AAAAAAAAAADV BwGFiGRYADzzEgDxoeF3EgMwAAIDJwASAQAAlfAAADkAPAAAABMAlfAAAKqHRQASAzAAAgMnAAAB AAAkAAAAOQA8AKEAAACIZFgApPYSABgVOwB3wrR3KAM4AGhWEwAgAQAA2LUVAAAAAAAAAAAA0PMS AJUriHcINoh3/////+DzEgAec+d3AAATAAgAFAAYAQAAbJxIAGibSACJOOh3AAAAAAAAAAAAAAAA AAAAAETaRABsnEgA9MIVAHlWEwB5m0gA/////2hWEwB32EQAbJxIACH5BAEAAFAALAAAAABTADQA QAj/AKEIHEiwoMGDCBMqXMiwYcIhAyRgmEixIgYWD1BosAEiwoUhIIc4hBJBAQ0hK2LE0KFgZMIB Fi22ADEywoyJNA42mWARwcENGDqIJBhgKMMHMZPONFjEYgeDFlpMuJHCIA0nBkEwSTqRREEaSiIk tLB14gAoDWIuLTgkgFu3LpygYMGTKxCEBOomDWIQJgAPLgewyNHQQhAdD1hwpaiycYkEhKGAqHrw QsQJE5QUCeCys+fPoEMvHBKXAGIlJVJjXjyxBIUbKIo0sCDaJQm6rHPr5lrAAMMIRIwyHAJDL9e1 nSFgaFkwAgXMP4QLhGmRCc2BATZcT5hgN/KRRBRT/9wwGgbrB0sKQpgQOWGAG5iPEBwCJEEBFwad xNgdk4XvgQ2UUN0O6RVkgASY+XBBbdJBMcQHNORAwABERNDgQhdYoIAJTVRQgkos6ECDCxfWZuKJ KIL2AQFI8TcRC0wkkMADNNLYAgsCVlTACCRslyJBNuWoWwEuUtSCBB04QZtCCnQgAQ2UfTbEDMZR VIAPMwih5ZZc+pBEWRMl0ASXWpqXlHw/EiTDfot955AQMWRg0BAjVITCQU1RNINwRGDFUBBVKuWj QDSUwMKhK/RgkAuHLklQDxgo4ehACghZUQJiYXeDotx5N6iDKYQaZUFO5AhDiUStwFpOBDkBgAkJ of+glw0osFmRmwsFgEJSgMUaKEUrZDrQERgAwBxCH4h3p0BHPIcZrgPYWmQDBgHxawFeNYcgAGc5 dIRi1DYUbZGXZkpEaiVIEMSnJHWQIw2oNgTCBuGmudASRzTRgkqQsWsvQhd8AEQODDzQQgFEWqRS ai3ccEAOAyhgQbz/VmzxxRhn7FAALjQAxA5CyMAADEmUnIQOKHRQxAAcLaixSwE0kMOX5LLWgg4k BPfyQBc4cYB4uSUggRBBsIyDBREsofTSFuBgwwBFzDBCdy/OcOy/R5hpsxAEEDDDAUnc8MAKZD9w gwQ6COEBEDZMrNAFRARRAQVC/HfiESv8WrN3OBf/iJAFJCCAH2hDdKD33kUuazEB0lZEgbAPgVDE A5itwFlzVFd0g8sEEdFtbQYoYbO/CeW1uUE2WGodVC1MhALnUKTQA8UANq4W6WOxAMNBNGAWn0Ep 3GBRtgMNgKZC5+qG6xIf4OC83wSlNcNBVE5QxEEMJNWeQA4IsZAOnhpEgkXTF2TBcz6x9cABP+l9 vEAo6KBQ5qP3ZfYNDn/qgugYfD4QSAbZweGu16oY2CAhrVMe7hIiBIqU4IALoc5i6iUQIMRgewVp 0UWaYCkjLdAgF0iCcZRgt4P0oIMW2QFbbvCqhPSOIgoAgRKqhKuEKEBrFrEcQvbHGh4YRAcxYALk /wxyk4kQUDC3+lQDEoC/G6wATKwZQYOWkIBfxWAH0gHBvlgAPbxgJgF+MwD4MIAr/exNcQIZgkRi UgFOAWkEE4iBUBxChBnKz3wkmJRAzLg3AhBkV0bKQQkH4oQqxmAGsPNWDH6QSIQMAACIwwABWZQD G1zoAkBo0Q8gGBob3ABWDkkBCBQwABJ4QAU+0IEqdXAAtRWBbS5YQrwiQIMfYEYJORgcii5whCGS JIa0GwlpBiCEBCwMBgPw5css4IQmwKACN4CBEHJQBCMcoQHYxKYTjFCEHAghCSsoQGOYAAMCNOCD O6tMBFygABs4wQRAiGcInBfLRqbznvjMZ4oCAgA7 --0__=4EBBFF08DFA388418f9e8a93df938690918c4EBBFF08DFA38841--

1 0

ITS#5860 slapd in openldap-2.4.16 still doesn't respect memory bounds
by linamat＠telco.md 17 Apr '09

17 Apr '09

I have tried openldap-2.4.16 (latest) BDB 4.7.25 with all patches from Oracle on Dell AMD64 RAM 4Gb, 8 CPUs, OS Solaris 10. According to ITS#5860 slapd should not allocate more memory than it was specified. In fact I have the same behaviour as it was with previous version (2.4.11). It correctly allocates 1.2 Gb via shared memory (for set_cachesize 300 MB). But slapd process continuosly grows in memory until 32-bit limit then crashes due to unavalable memory resources. I need to mention bdb database size is less then 1 GB. After restart it rapidly consumes 1.5 GB RSS in few minutes and then it grows beyond the limit during 24 hours. The more queries are processing the more memory it eats. I am using this database for logging which size grows. The question is: is it possible to use 32-bit openldap with relatively large database sizes that override 32-bit per-process memory space? My slapd.conf contains: threads 64 concurrency 50 cachesize 200000 dncachesize 400000 idlcachesize 600000 shm_key 10 DB_CONFIG: set_cachesize 0 300097152 1 set_lk_max_locks 1000000 set_lk_max_lockers 1000000 set_lk_max_objects 1000000 set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152 ls -ls ./openldap-data total 1212876 -rw-r--r-- 1 slapd nobody 640 Apr 17 08:42 DB_CONFIG -rw------- 1 slapd nobody 8 Apr 16 10:50 __db.001 -rw-r--r-- 1 slapd nobody 4096 Apr 16 10:50 alock -rw------- 1 slapd nobody 6053888 Apr 17 09:50 cn.bdb -rw------- 1 slapd nobody 1024000 Apr 17 09:50 dhcpHWAddress.bdb -rw------- 1 slapd nobody 96583680 Apr 17 09:50 dn2id.bdb -rw------- 1 slapd nobody 515637248 Apr 17 09:50 id2entry.bdb -rw------- 1 slapd nobody 1343488 Apr 17 09:50 objectClass.bdb Any help would be much appreciated. Regards, Sergey.

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2009