[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: OpenLDAP crash upon modify error (ITS#2136)
I've just tracked down the remaining failure paths, please try again with
slapd/mods.c -r1.15 from CVS.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support
> -----Original Message-----
> From: owner-openldap-bugs@OpenLDAP.org
> [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
> bruno.spieler@atosorigin.com
> Sent: Friday, October 11, 2002 5:38 AM
> To: openldap-its@OpenLDAP.org
> Subject: Re: OpenLDAP crash upon modify error (ITS#2136)
>
>
> Hi,
>
> I tried with HEAD, but the same trouble occured
>
> Here's the stack from dbx:
> t@5 (l@1) terminated by signal SEGV (no mapping at the fault address)
> Current function is lutil_debug
> 314 vsnprintf( buffer, sizeof(buffer), fmt, vl );
> (/opt/users8/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) where
> current thread: t@5
> [1] strlen(0x0, 0x0, 0x1792bf, 0x7efefeff, 0x81010100,
> 0x0), at 0xff033344
> [2] _doprnt(0x0, 0xfe10023b, 0x0, 0x1b2229, 0x0, 0x1792c2),
> at 0xff083090
> [3] vsnprintf(0xfe1007b8, 0x7fffffff, 0x1792a8, 0xfe101808,
> 0x1c4a90,
> 0xfe101794), at 0xff085204
> =>[4] lutil_debug(debug = 4095, level = 4, fmt = 0x1792a8
> "bdb_modify_internal: %d %s\n", ...), line 314 in "debug.c"
> [5] bdb_modify_internal(be = 0x1c28b0, conn = 0x202358, op
> = 0x212468, tid
> = 0x2172c8, modlist = 0x1c4ac8, e = 0x215790, text =
> 0xfe1019dc, textbuf =
> 0xfe1018dc "", textlen = 256U), line 65 in "modify.c"
> [6] bdb_modify(be = 0x1c28b0, conn = 0x202358, op = 0x212468, dn =
> 0xfe101c0c, ndn = 0xfe101c04, modlist = 0x1c4ac8), line 411
> in "modify.c"
> [7] glue_back_modify(b0 = 0x1fb8d8, conn = 0x202358, op =
> 0x212468, dn =
> 0xfe101c0c, ndn = 0xfe101c04, mod = 0x1c4ac8), line 473 in
> "backglue.c"
> [8] do_modify(conn = 0x202358, op = 0x212468), line 358 in
> "modify.c"
> [9] connection_operation(ctx = 0x212538, arg_v = 0x1c4460),
> line 970 in
> "connection.c"
> [10] ldap_int_thread_pool_wrapper(xpool = 0x1b81f0), line
> 431 in "tpool.c"
>
> At level 5, I get *text=0
>
> Hope it will help
>
> Bruno
>
> ----- Original Message -----
> From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
> To: <bruno.spieler@atosorigin.com>
> Cc: <openldap-its@OpenLDAP.org>
> Sent: Friday, October 11, 2002 3:07 AM
> Subject: Re: OpenLDAP crash upon modify error (ITS#2136)
>
>
> > This is believed fixed in HEAD and OPENLDAP_REL_ENG_2_1
> > (available from AnonCVS). Please test. Thanks, Kurt
> >
> > At 10:09 AM 2002-10-09, bruno.spieler@atosorigin.com wrote:
> > >Full_Name: Bruno Spieler
> > >Version: 2.1.4
> > >OS: Solaris 8
> > >URL:
> > >Submission from: (NULL) (195.68.44.148)
> > >
> > >
> > >Hi here
> > >
> > >I've got a 2.1.4 Openldap software compiled on an UltraSparc under
> Solaris 8
> > >with SUNWPro compiler, with DEBUG support, but no
> NEW_LOGGING define.
> > >
> > >When I try to add an attribute (let's say description) to
> an entry, using
> a
> > >value already present in this entry for this attribute, my OpenLDAP
> server
> > >crashes.
> > >
> > >The slapd is launched with a "-d" parameter
> > >
> > >The problem is in the Debug macro which seems to map to
> lutil_debug()
> function
> > >in "liblber/debug.c".
> > >A call to vsnprintf is performed (HAVE_VSNPRINTF is defined) with a
> format
> > >"bdb_modify_internal: %d %s\n" in file back-bdb/modify.c,
> but the '%s' is
> > >associated with a string pointer ("*text" in my case,
> expected to contain
> a
> > >human readable description of the error), which has been
> left to NULL by
> the
> > >previous call to modify_add_values() (at least one control
> path in this
> function
> > >does not set the text variable nor feed the error buffer).
> > >
> > >My Solaris (my compiler ?) does not seem to like NULL
> string pointer. The
> > >following program crashes for example (don't expect
> anything more clever
> from
> > >strlen !):
> > >
> > >#include <stdio.h>
> > >
> > >main()
> > >{
> > > printf("Hello %s\n", NULL);
> > >}
> > >
> > >By the way, after the crash has occured, the concerned
> back-end is not
> usable
> > >anymore even if you restart the slapd : slapd seems to be
> waiting for a
> lock in
> > >a transaction or whatever.
> > >Using the great db_recover tool from SleepyCat solves the problem !
>
>