[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64



Looks like a duplicate of ITS#6657; I have already investigated that bug
to no avail.  Apparently, a pointer to stack-residing data is erroneously
freed.  You may be able to find out more info by checking where this
happens from the core.  I can't take care of this issue right now as I'd
need to give it incredibly low priority.

p.

> Ok, thanks for the answer
>
> This is the new backtrace:
>
> Core was generated by `./slapd -d -1'.
> Program terminated with signal 11, Segmentation fault.
> [New process 1656]
> [New process 1570]
> [New process 1573]
> #0  0x0000000000491ac5 in slap_sl_free (ptr=0xffffffd2028b00d0,
> ctx=0x28a3120)
>     at sl_malloc.c:490
> 490                if ( tmpp[-1] & 1 ) {
> (gdb) bt
> #0  0x0000000000491ac5 in slap_sl_free (ptr=0xffffffd2028b00d0,
> ctx=0x28a3120)
>     at sl_malloc.c:490
> #1  0x00000000004d562e in backsql_entry_clean (op=0x28a9b10, e=0x42e98a40)
>     at search.c:2680
> #2  0x00000000004d4e8f in backsql_search (op=0x28a9b10, rs=0x42e99ca0)
>     at search.c:2517
> #3  0x0000000000429f5c in fe_op_search (op=0x28a9b10, rs=0x42e99ca0)
>     at search.c:366
> #4  0x00000000004298c7 in do_search (op=0x28a9b10, rs=0x42e99ca0)
>     at search.c:217
> #5  0x0000000000426952 in connection_operation (ctx=0x42e99df0,
>     arg_v=0x28a9b10) at connection.c:1109
> #6  0x0000000000426ede in connection_read_thread (ctx=0x42e99df0,
> argv=0x9)
>     at connection.c:1245
> #7  0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=0x26f6ea0)
>     at tpool.c:685
> #8  0x00007fddda10cfc7 in start_thread () from /lib/libpthread.so.0
> #9  0x00007fddd9e8264d in clone () from /lib/libc.so.6
> #10 0x0000000000000000 in ?? ()
>
>
>
>
>
>
> 2010/11/1 <masarati@aero.polimi.it>
>
>> > Full_Name: Andrés Marenco Zúñiga
>> > Version: 2.4.23 (20100719)
>> > OS: Debian 5.06 amd64
>> > URL:
>> > Submission from: (NULL) (201.198.99.66)
>> >
>> >
>> > I'm getting a segfault while doing any search in openldap. This is my
>> > configuration:
>> >
>> > Debian 5.06 amd64 (kernel 2.6.26-2-amd64)
>> > OpenLDAP 2.4.23 (20100719)
>> > UnixODBC 2.3.0
>> > PostgreSQL 8.2.10
>> > psqlodbc 09.00.0101
>> >
>> >
>> >
>> #############################################################################
>> > slapd.conf (the relevant parts)
>> >
>> #############################################################################
>> > include
>> /var/lib/openldap/etc/openldap/schema/core.schema
>> > include
>> /var/lib/openldap/etc/openldap/schema/cosine.schema
>> > include
>> /var/lib/openldap/etc/openldap/schema/inetorgperson.schema
>> >
>> > pidfile               /var/lib/openldap/var/slapd.pid
>> > argsfile      /var/lib/openldap/slapd.args
>> >
>> > database      sql
>> > suffix                "dc=example,dc=com"
>> > rootdn                "cn=root,dc=example,dc=com"
>> > rootpw                secret
>> > dbname                PgSQL
>> > dbuser                ""
>> > dbpasswd      ""
>> > insentry_stmt "insert into ldap_entries
>> (id,dn,oc_map_id,parent,keyval)
>> > values
>> > ((select max(id)+1 from ldap_entries),?,?,?,?)"
>> > upper_func    "upper"
>> > strcast_func  "text"
>> > concat_pattern        "?||?"
>> > has_ldapinfo_dn_ru    no
>> >
>> > lastmod               off
>> >
>> >
>> >
>> >
>> #############################################################################
>> > odbcinst.ini
>> >
>> #############################################################################
>> > [PostgreSQL]
>> > Description=ODBC for PostgreSQL
>> > Driver=/usr/local/lib/psqlodbcw.so
>> >
>> >
>> >
>> #############################################################################
>> > odbc.ini
>> >
>> #############################################################################
>> > [PgSQL]
>> > Driver=/usr/local/lib/psqlodbcw.so
>> > Description=Connection to LDAP/POSTGRESQL
>> > Server=xxx.xxx.xxx.xxx
>> > Port=5432
>> > Protocol=6.4
>> > FetchBufferSize=99
>> > Database=db
>> > Username=user
>> > ReadOnly=no
>> > CommLog=1
>> >
>> >
>> >
>> >
>> >
>> >
>> > slapd starts fine, but when I make any search this is what I'm
>> getting:
>> >
>> > <= send_search_entry: conn 1000 exit.
>> > send_ldap_result: conn=1000 op=2 p=3
>> > send_ldap_result: err=0 matched="" text=""
>> > send_ldap_response: msgid=3 tag=101 err=0
>> > ber_flush2: 14 bytes to sd 11
>> >   0000:  30 0c 02 01 03 65 07 0a  01 00 04 00 04 00
>> 0....e........
>> > ldap_write: want=14, written=14
>> >   0000:  30 0c 02 01 03 65 07 0a  01 00 04 00 04 00
>> 0....e........
>> > conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
>> > Segmentation Fault (Core Dumped)
>> >
>> >
>> >
>> > in the syslog this is what I have:
>> >
>> > Oct 29 17:53:17 td-server slapd[32026]: conn=1000 op=2 SEARCH RESULT
>> > tag=101
>> > err=0 nentries=1 text=
>> > Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]:
>> segfault
>> at
>> > ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000]
>> >
>> >
>> >
>> > and the gdb backtrace shows this:
>> >
>> > Core was generated by `/var/lib/openldap/libexec/slapd -d -1'.
>> > Program terminated with signal 11, Segmentation fault.
>> > [New process 31991]
>> > [New process 31987]
>> > [New process 31990]
>> > #0  0x000000000046c23b in ?? ()
>> > #1  0x0000000000499903 in ?? ()
>> > #2  0x000000000049e01b in ?? ()
>> > #3  0x000000000041ed51 in ?? ()
>> > #4  0x000000000041f54c in ?? ()
>> > #5  0x000000000041cb5f in ?? ()
>> > #6  0x000000000041d7dc in ?? ()
>> > #7  0x00000000004c8760 in ?? ()
>> > #8  0x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0
>> > #9  0x00007fe1a45d764d in clone () from /lib/libc.so.6
>> > #10 0x0000000000000000 in ?? ()
>>
>> This trace is useless; since the issue appears to be repeatable, you
>> should retry with slapd built with debugging symbols and unstripped.
>>
>> >
>> >
>> >
>> >
>> > Everything works fine in 32bits (Debian 5.0 i386), but it fails with
>> > 64bits.
>> >
>> > Any idea?
>> >
>> Moreover, you may want to try with HEAD code, where some modifications
>> to
>> deal with 64 bit (long int) key values.  Should be unrelated, but just
>> in
>> case...
>>
>> p.
>>
>>
>>
>>
>
>
> --
> Andrés Marenco Zúñiga
> Equipo de Desarrollo
> TEC_Digital
>