openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

(ITS#7151) slapd segfaults when terminated
by jvcelak＠redhat.com 03 Feb '12

03 Feb '12

Full_Name: Jan Vcelak Version: 2.4.29 - git ad04676 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.165.68.229) I'm getting a slapd segfault when the server is being terminated. ^C4f2c5f43 daemon: shutdown requested and initiated. 4f2c5f43 daemon: closing 7 4f2c5f43 daemon: closing 8 4f2c5f43 slapd shutdown: waiting for 0 operations/tasks to finish 4f2c5f43 slapd shutdown: initiated 4f2c5f43 ====> bdb_cache_release_all 4f2c5f43 slapd destroy: freeing system resources. make: *** [run] Segmentation fault Used configuration: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /root/re24/server1/run/slapd.args olcPidFile: /root/re24/server1/run/slapd.pid dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib64/openldap dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c n=auth" manage by * none dn: olcDatabase={1}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=redhat,dc=bug olcRootDN: cn=Manager,dc=redhat,dc=bug olcRootPW: secret olcDbDirectory: /root/re24/server1/db olcDbIndex: objectClass eq,pres olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub Backtrace: #0 __GI___libc_free (mem=0x185) at malloc.c:2972 ar_ptr = <optimized out> p = <optimized out> hook = 0 #1 0x0000555555727d29 in ber_memfree_x (p=0x185, ctx=0x0) at ../../../libraries/liblber/memory.c:152 __PRETTY_FUNCTION__ = "ber_memfree_x" #2 0x00007ffff489220a in ldap_int_destroy_global_options () at ../../../libraries/libldap/init.c:496 gopts = 0x5555559bcfc0 #3 0x00007ffff7df0b1e in _dl_close_worker (map=map@entry=0x555555a811b0) at dl-close.c:266 array = 0x7ffff4abe630 sz = 1 imap = 0x555555a816c0 i = <optimized out> dl_close_state = pending nsid = 0 ns = 0x7ffff7ffd000 any_tls = false nloaded = 28 used = '\001' <repeats 24 times>, "\000\000\000\001" done = '\001' <repeats 24 times>, "\000\000\000\001" maps = {0x7ffff7ffe2a8, 0x7ffff7ffe838, 0x7ffff7ffa658, 0x7ffff7ffab20, 0x7ffff7ff3000, 0x7ffff7ff34d0, 0x7ffff7ff3998, 0x7ffff7ff2000, 0x7ffff7ff24c8, 0x7ffff7ff2990, 0x7ffff7ff1000, 0x7ffff7ff14d0, 0x7ffff7ff1998, 0x7ffff7ff0000, 0x7ffff7ff04c8, 0x7ffff7ff0990, 0x7ffff7fef000, 0x7ffff7fef4c8, 0x7ffff7fef990, 0x7ffff7fee000, 0x7ffff7fee528, 0x7ffff7ffd998, 0x7ffff7fed000, 0x555555a48f30, 0x555555a811b0, 0x555555a816c0, 0x555555a81bd0, 0x555555ac3420} idx = <optimized out> done_index = <optimized out> do_audit = false unload_any = <optimized out> scope_mem_left = <optimized out> unload_global = <optimized out> first_loaded = <optimized out> r = <optimized out> tls_free_start = <optimized out> tls_free_end = <optimized out> #4 0x00007ffff7df151e in _dl_close (_map=0x555555a811b0) at dl-close.c:770 map = 0x555555a811b0 #5 0x00007ffff7debb66 in _dl_catch_error (objname=0x555555a81160, errstring=0x555555a81168, mallocedp=0x555555a81158, operate=0x7ffff55660d0 <dlclose_doit>, args=0x555555a811b0) at dl-error.c:178 errcode = 0 old = 0x0 c = {objname = 0x7ffff76100d8 "X\a", errstring = 0x0, malloced = 251, env = {{__jmpbuf = {93824997658960, -5310358512699590611, 93824997659056, 140737488348192, 0, 0, -5310372595880576979, -5310355285852702675}, __mask_was_saved = -142437680, __saved_mask = {__val = {0, 140737488348192, 0, 0, 93824997688544, 140737351954868, 5, 0, 4116075984, 140737351954868, 93824997690256, 93824997688544, 140737345918272, 140737351980421, 0, 93824997571648}}}}} catchp = 0x7ffff7fe9738 #6 0x00007ffff556662c in _dlerror_run (operate=operate@entry=0x7ffff55660d0 <dlclose_doit>, args=0x555555a811b0) at dlerror.c:164 result = 0x555555a81150 #7 0x00007ffff55660ff in __dlclose (handle=<optimized out>) at dlclose.c:48 No locals. #8 0x00007ffff76220e1 in _sasl_done_with_plugins () at dlopen.c:541 libptr = 0x555555a81130 libptr_next = 0x0 #9 0x00007ffff7619ffb in sasl_done () at common.c:674 No locals. #10 0x0000555555624d25 in slap_sasl_destroy () at ../../../servers/slapd/sasl.c:1190 No locals. #11 0x00005555555eebf0 in slap_destroy () at ../../../servers/slapd/init.c:249 rc = 0 #12 0x000055555558129f in main (argc=6, argv=0x7fffffffe428) at ../../../servers/slapd/main.c:1033 i = 6 no_detach = 1 rc = 0 urls = 0x555555a480b0 "ldap://ldapserver1.redhat.bug:1389 ldaps://ldapserver1.redhat.bug:1636" username = 0x0 groupname = 0x0 sandbox = 0x0 syslogUser = 160 pid = 32767 waitfds = {-166376544, 32767} g_argc = 6 g_argv = 0x7fffffffe428 configfile = 0x0 configdir = 0x555555a48090 "slapd.d" serverName = 0x7fffffffe6bd "slapd" serverMode = 1 scp = 0x0 scp_entry = 0x0 debug_unknowns = 0x0 syslog_unknowns = 0x0 serverNamePrefix = 0x55555572b818 "" l = 1 slapd_pid_file_unlink = 1 slapd_args_file_unlink = 1 firstopt = 0 __PRETTY_FUNCTION__ = "main" Id Target Id Frame * 1 Thread 0x7ffff7fe9740 (LWP 15364) "slapd" 0x000055555558129f in main (argc=6, argv=0x7fffffffe428) at ../../../servers/slapd/main.c:1033 OpenLDAP from tag OPENLDAP_REL_ENG_2_4_29 (ad0467699d9054e32a5530e93e28bd4194344d3d), probably also present in previous versions. Fedora 17 x86_64, cyrus-sasl-2.1.23-28.fc17.x86_64

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com > wrote: > >> On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: >> >>> Mattias Andersson wrote: >>>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>>> >>>>> Please provide a full gdb backtrace from the assertion failure. I've >>>>> reproduced this configuration locally but see no crash using >>>>> ldapsearch. >>>>> I don't have the Softerra browser. >>>> >>>> Ok, see attachment. The problem is not reproducible with ldapsearch. >>> >>> Please see if the attached patch alters the behavior. Thanks. >> >> I'm getting an error that MozNSS is not found when I run ./configure. >> >> Mattias > > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. Ok, I didn't apply the patch yet, but now I'm getting a different error than before (before I was using OpenLDAP 2.4.25 from the Ubuntu package repository): cornelian build_unix # /usr/local/libexec/slapd -d 256 -f /etc/ldap/slapd.conf 4f2c5a69 @(#) $OpenLDAP: slapd 2.4.28 (Feb 1 2012 02:31:50) $ root@cornelian:/root/openldap/openldap-2.4.28/servers/slapd 4f2c5a69 hdb_db_open: database "dc=rss,dc=chalmers,dc=se": unclean shutdown detected; attempting recovery. 4f2c5a69 hdb_monitor_db_open: monitoring disabled; configure monitor database to enable 4f2c5a69 slapd starting 4f2c5ac2 conn=1000 fd=12 ACCEPT from IP=127.0.0.1:39354 (IP=0.0.0.0:389) 4f2c5ac2 conn=1000 op=0 BIND dn="" method=128 4f2c5ac2 conn=1000 op=0 RESULT tag=97 err=0 text= 4f2c5ac2 conn=1000 op=1 SRCH base="dc=chalmers,dc=se" scope=2 deref=0 filter="(objectClass=*)" 4f2c5ac2 conn=1000 op=1 SRCH attr=1.1 /usr/local/libexec/slapd: symbol lookup error: /usr/local/libexec/openldap/back_ldap-2.4.so.2: undefined symbol: ldap_get_message_ber This error also happens with ldapsearch. Mattias

1 0

Re: ~*~ [spam] Re: (ITS#7143) Assertion error (crash); using relay backend and translucent ove
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 22:24:36 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Friday, February 03, 2012 10:19 PM +0100 Mattias Andersson > <mattias(a)centaurix.com> wrote: > >> I'm having some problems with the BDB library: >> >> 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected >> Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January >> 28, 2011) > > You built against BDB 5.1.29, but you have BDB 5.1.25 installed. This > would definitely happen if one system was updated when the other was not. Actually I did install BDB 5.1.29, but probably I need to adjust some library path or change a symlink. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by mattias＠centaurix.com 03 Feb '12

03 Feb '12

On Fri, 03 Feb 2012 20:26:01 +0100, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > Hi Mattias, > > Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if > possible. I'm having some problems with the BDB library: 4f2c4dd3 bdb_back_initialize: BDB library version mismatch: expected Berkeley DB 5.1.29: (October 25, 2011), got Berkeley DB 5.1.25: (January 28, 2011) I'll see if I can figure it out. Mattias

1 0

Re: (ITS#7143) Assertion error (crash); using relay backend and translucent overlay
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Tuesday, January 31, 2012 10:41 AM +0000 mattias(a)centaurix.com wrote: > On Tue, 31 Jan 2012 03:56:06 +0100, Howard Chu <hyc(a)symas.com> wrote: > >> Mattias Andersson wrote: >>> On Tue, 31 Jan 2012 02:27:05 +0100, Howard Chu<hyc(a)symas.com> wrote: >>> >>>> Please provide a full gdb backtrace from the assertion failure. I've >>>> reproduced this configuration locally but see no crash using >>>> ldapsearch. >>>> I don't have the Softerra browser. >>> >>> Ok, see attachment. The problem is not reproducible with ldapsearch. >> >> Please see if the attached patch alters the behavior. Thanks. > > I'm getting an error that MozNSS is not found when I run ./configure. > > Mattias Hi Mattias, Any update? We would like to get a fix for this into OpenLDAP 2.4.29 if possible. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by quanah＠zimbra.com 03 Feb '12

03 Feb '12

--On Friday, February 03, 2012 10:03 AM +0100 David Coutadeur <david.coutadeur(a)linagora.com> wrote: > > That was my first try. > I have used the option --enable-debug in the configure command, which > seems to produce AC_CFLAGS = -g -O2, itself reinjected in CFLAGS = > $(AC_CFLAGS) $(DEFS) in the Makefile. > > However this has lead to an unusable stacktrace. Thus I preferred using > the binary file (with debug symbols) pointed by > openldap-src/servers/slapd : > /opt/openldap-src/servers/slapd/.libs/lt-slapd > This gave me the stacktrace I first sent. By default, "make install" will strip the binaries of the debugging symbols. You have to prevent that by running it as: make install STRIP="" --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 03 Feb '12

03 Feb '12

Thanks. A fix for this is now in git master (5584e5b) > Le 03/02/2012 18:15, Howard Chu a écrit : >> david.coutadeur(a)linagora.com wrote: >>> I have reproduced the bug with a fresh new HEAD version yesterday, >>> including : >>> 02/02/2012 Howard Chu ITS#7146 fix prev commit >> >> Can you include a "bt full" gdb backtrace on this? >> >>> Le 02/02/2012 20:25, Michael Ströder a écrit : >>>> dcoutadeur(a)linagora.com wrote: >>>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>>>> version) >>>> >>>> Which exact git version? Did you build RE24 from git already containing >>>> the fix for ITS#7113 (dup of ITS#6928)? -- -- 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#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

Here it is. Program terminated with signal 11, Segmentation fault. #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 2118 for ( m2 = mt->mt_mods; m2->mi_next != mi; (gdb) bt full #0 0x0818d9c2 in syncprov_op_mod (op=0x89b2fe0, rs=0x8c9b1108) at syncprov.c:2118 m2 = 0x0 mt = 0x89cd028 mtdummy = {mt_mods = 0x889e468, mt_tail = 0x89b2fe0, mt_op = 0x89b2fe0, mt_mutex = {__data = {__lock = 48, __count = 2358971544, __owner = 135135137, __kind = 144388064, __nusers = 2358972680, {__spins = 16843008, __list = {__next = 0x1010100}}}, __size = "0\000\000\000\230\f\233\214\241\377\r\b\340/\233\b\b\021\233\214\000\001\001\001", __align = 48}} mi = 0x8bcae2a0 on = <value optimized out> si = 0x87cbfa0 cb = 0x8bcae258 opc = 0x8bcae268 have_psearches = 1 #1 0x080dff34 in overlay_op_walk (op=0x89b2fe0, rs=0x8c9b1108, which=op_add, oi=0x87c98a8, on=0x87cbe98) at backover.c:661 rc = 144388064 #2 0x080e049a in over_op_func (op=0x89b2fe0, rs=0x8c9b1108, which=op_add) at backover.c:723 oi = 0x87c98a8 on = 0x87cbe98 be = 0x8793c48 db = {bd_info = 0x87cbe98, bd_self = 0x8793c48, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\000\000\001\001", '\000' <repeats 12 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 = 0}, be_suffix = 0x87c93f8, be_nsuffix = 0x8796f70, be_schemadn = { bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 24, bv_val = 0x87c8b30 "cn=Manager,dc=afp,dc=com"}, be_rootndn = {bv_len = 24, bv_val = 0x87c8d40 "cn=manager,dc=afp,dc=com"}, be_rootpw = {bv_len = 38, bv_val = 0x87961f8 "{SSHA}rEmMhg3MU5xkQX5Ng92tH4WzGMlA+nGU"}, be_max_deref_depth = 15, be_def_limit = { lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 15000, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x87cbe40, be_acl = 0x0, 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 = 0x889b1a0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0, __nusers = 0, {__spins = 0, __list = {__next = 0x0}}}, __size = '\000' <repeats 23 times>, __align = 0}, be_syncinfo = 0x87cc1c8, be_pb = 0x0, be_cf_ocs = 0x8212020, be_private = 0x8793d48, be_next = { stqe_next = 0x87cc050}} cb = {sc_next = 0x0, sc_response = 0x80dfce0 <over_back_response>, sc_cleanup = 0, sc_private = 0x87c98a8} sc = <value optimized out> rc = <value optimized out> __PRETTY_FUNCTION__ = "over_op_func" #3 0x0807eeb9 in fe_op_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:334 repl_user = 0 rc = <value optimized out> bd = 0x8215ca0 textbuf = "\000\000\000\000\210\032\234\b0\033\233\214@q(\000\030\000\000\000\000\000\000\000\"\203%\000\b\241%\000\270\255\234\b\030lv\b\002\000\000\000\250\016\233\214-[\v\b\270\255\234\b\224\016\233\214\001\000\000\000\000\000\000\000\340i\234\b\000\000\000\000\n\000\000\000\001\000\000\000\270\027v\b\n\000\000\000\310\f\234\b\320\032\234\b\030lv\b\270\255\234\b\370\016\233\214O>\t\b\002\000\000\000\030Vt\b\370\016\233\214\261:\t\b@et\bpu\234\b'<\202\000\000\000\000\000\f\000\000\000\227V\235\b\207~\000\000\224\225d\000\300rv\b\300rv\b\370\016\233\214\335Pa\000\000V!\b,I\337\215\030\017\233\214\325\020\b\b\000V!\bpu\234\b\000\000\000\000\270\255\234\b\200H\337\215\000\000\000\000H\017\233\214G\353\a\b\300rv\b\300rv\b\001\000\000\---Type <return> to continue, or q <return> to quit--- 000H\017\233\214\020\000\000\000@I\337\215\377\377\377\377" __PRETTY_FUNCTION__ = "fe_op_add" #4 0x0807f7a3 in do_add (op=0x89b2fe0, rs=0x8c9b1108) at add.c:194 ber = <value optimized out> last = 0x89d56b1 "" dn = {bv_len = 38, bv_val = 0x89d55d8 "uid=dcoutadeur,ou=People,dc=afp,dc=com"} len = 28 tag = <value optimized out> modlist = 0x89ce650 modtail = 0x89becbc tmp = {sml_mod = {sm_desc = 0x80cb2aa, sm_values = 0x89c7570, sm_nvalues = 0x0, sm_numvals = 2358972600, sm_op = 0, sm_flags = 0, sm_type = {bv_len = 12, bv_val = 0x89d5697 "userPassword"}}, sml_next = 0x823c27} textbuf = "\000\000\000\000\000\000\000\000X\360\233\b\006\240\031\000\240\261\211\b\000\000\000\000\000\000\000\000@q(\000\000\000\000\000\000\000\000\000\060X\234\b\310\301|\b\000\000\000\000Te\031\000\000\000\000\000@q(\000\364_(\000\220\033\233\214\000\000\000\000\313؛\b\240\375\233\b\370\017\233\214T\213\202\000b\213\202\000;\334\022\000/\000\000\000\313؛\b\b\000\000\000\201\254\031\000\f\020\233\214<\004\023\000\270\020\233\214\312\315\022\000\260 \233\b\313؛\b\b\000\000\000\001\200\255\373\340\060\233\b\340\060\233\b\340\060\233\b\340\060\233\b\356\060\233\b\337\061\233\b\340\060\233\b\337\061\233\b,\000\000\000@q(", '\000' <repeats 13 times>, "\001\000\000\000\000\000\000\000\060\000\000\000\000\000\000\b", '\000' <repeats 16 times>, "\030X\234\b\000\000\000\000\001\000\000\000\004\000\020\000\350\021\233\214\310\020\233\214" rc = <value optimized out> freevals = <value optimized out> oex = {oe = {oe_next = {sle_next = 0x0}, oe_key = 0x807f0c0}, oe_db = 0x0} #5 0x0807759d in connection_operation (ctx=0x8c9b11e8, arg_v=0x89b2fe0) at connection.c:1138 rc = <value optimized out> cancel = <value optimized out> rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, 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} tag = 104 opidx = SLAP_OP_ADD conn = 0xb7efd014 memctx = 0x89b3358 memctx_null = 0x0 __PRETTY_FUNCTION__ = "connection_operation" #6 0x08077f6d in connection_read_thread (ctx=0x8c9b11e8, argv=0x2f) at connection.c:1274 s = <value optimized out> #7 0x006145e4 in ldap_int_thread_pool_wrapper (xpool=0x87687a8) at tpool.c:685 task = 0x89b2970 work_list = <value optimized out> ctx = {ltu_id = 2358975376, ltu_key = {{ltk_key = 0x8076270, ltk_data = 0x89b3268, ltk_free = 0x8076340 <conn_counter_destroy>}, {ltk_key = 0x80cb0e0, ltk_data = 0x89b3358, ltk_free = 0x80cb110 <slap_sl_mem_destroy>}, {ltk_key = 0x889b1b0, ltk_data = 0x89b78b0, ltk_free = 0x8125cf0 <bdb_reader_free>}, {ltk_key = 0x808b900, ltk_data = 0x0, ltk_free = 0x808b710 <slap_op_q_destroy>}, {ltk_key = 0x889ebe0, ltk_data = 0x89b9f78, ltk_free = 0x8125cf0 <bdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 27 times>}} kctx = <value optimized out> keyslot = 242 hash = 5209330 ---Type <return> to continue, or q <return> to quit--- __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #8 0x00821832 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9 0x0020346e in clone () from /lib/libc.so.6 No symbol table info available. Le 03/02/2012 18:15, Howard Chu a écrit : > david.coutadeur(a)linagora.com wrote: >> I have reproduced the bug with a fresh new HEAD version yesterday, >> including : >> 02/02/2012 Howard Chu ITS#7146 fix prev commit > > Can you include a "bt full" gdb backtrace on this? > >> Le 02/02/2012 20:25, Michael Ströder a écrit : >>> dcoutadeur(a)linagora.com wrote: >>>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>>> version) >>> >>> Which exact git version? Did you build RE24 from git already containing >>> the fix for ITS#7113 (dup of ITS#6928)? >

1 0

Re: (ITS#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by hyc＠symas.com 03 Feb '12

03 Feb '12

david.coutadeur(a)linagora.com wrote: > I have reproduced the bug with a fresh new HEAD version yesterday, > including : > 02/02/2012 Howard Chu ITS#7146 fix prev commit Can you include a "bt full" gdb backtrace on this? > Le 02/02/2012 20:25, Michael Ströder a écrit : >> dcoutadeur(a)linagora.com wrote: >>> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >>> version) >> >> Which exact git version? Did you build RE24 from git already containing >> the fix for ITS#7113 (dup of ITS#6928)? -- -- 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#7150) SEGFAULT in openldap-2.4.28 & 2.4.29
by david.coutadeur＠linagora.com 03 Feb '12

03 Feb '12

I have reproduced the bug with a fresh new HEAD version yesterday, including : 02/02/2012 Howard Chu ITS#7146 fix prev commit Le 02/02/2012 20:25, Michael Ströder a écrit : > dcoutadeur(a)linagora.com wrote: >> I have encountered a bug on openldap 2.4.28 and openldap 2.4.29 (ie git >> version) > > Which exact git version? Did you build RE24 from git already containing > the fix for ITS#7113 (dup of ITS#6928)? > > Ciao, Michael.

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