[Issue 9421] New: SIGSEGV in the MMR synchro
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9421
Issue ID: 9421
Summary: SIGSEGV in the MMR synchro
Product: OpenLDAP
Version: 2.4.56
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: benjamin.demarteau(a)liege.be
Target Milestone: ---
We are in the process of migrating from a single outdated node to an up to date
MMR cluster. Through this process we write LSC synchronizations from the old
server to the new server so we can keep the old server around.
Our preliminary tests show that when LSC hammers the ldap using multiple
threads while another node is included in the replication, we get segmentation
faults with the following backtrace:
#0 0x00007f7f578748ef in __strncasecmp_l_avx () from /lib64/libc.so.6
#1 0x000056094a7ca298 in avl_find (root=0x56094bb28820,
data=data@entry=0x7f7e74000cd0, fcmp=fcmp@entry=0x56094a7166a0
<oc_index_name_cmp>) at avl.c:545
#2 0x000056094a716bde in oc_bvfind (ocname=0x7f7e74000cd0) at oc.c:186
#3 oc_bvfind (ocname=ocname@entry=0x7f7e74000cd0) at oc.c:178
#4 0x000056094a70ec5a in objectSubClassMatch (matchp=0x7f7e5fff8c8c,
flags=256, syntax=<optimized out>, mr=<optimized out>, value=<optimized out>,
assertedValue=0x7f7e74000cd0) at schema_prep.c:214
#5 0x000056094a6e9fb9 in ordered_value_match
(match=match@entry=0x7f7e5fff8c8c, ad=0x56094bb184e0,
mr=mr@entry=0x56094bb09810, flags=flags@entry=256, v1=v1@entry=0x7f7e5810f470,
v2=v2@entry=0x7f7e74000cd0,
text=0x7f7e5fff8c90) at value.c:693
#6 0x000056094a6ec44d in test_ava_filter (op=op@entry=0x7f7e5fff90c0,
e=e@entry=0x56094bb54a88, ava=0x7f7e74000cc8, type=type@entry=163) at
filterentry.c:777
#7 0x000056094a6ecfec in test_filter (op=op@entry=0x7f7e5fff90c0,
e=e@entry=0x56094bb54a88, f=f@entry=0x7f7e74000d08) at filterentry.c:88
#8 0x000056094a6ecc81 in test_filter_and (flist=<optimized out>,
e=0x56094bb54a88, op=0x7f7e5fff90c0) at filterentry.c:879
#9 test_filter (op=op@entry=0x7f7e5fff90c0, e=0x56094bb54a88, f=<optimized
out>) at filterentry.c:118
#10 0x00007f7f5382c58f in syncprov_matchops (op=op@entry=0x7f7e5fff9c80,
opc=opc@entry=0x7f7e58001808, saveit=saveit@entry=0) at syncprov.c:1393
#11 0x00007f7f5382e37f in syncprov_op_response (op=0x7f7e5fff9c80,
rs=<optimized out>) at syncprov.c:2115
#12 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e5fff9c80,
rs=rs@entry=0x7f7e5fff9c10) at result.c:508
#13 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e5fff9c80,
rs=rs@entry=0x7f7e5fff9c10) at result.c:583
#14 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e5fff9c80,
rs=0x7f7e5fff9c10) at result.c:861
#15 0x000056094a7a86fd in mdb_add (op=0x7f7e5fff9c80, rs=0x7f7e5fff9c10) at
add.c:435
#16 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e5fff9c80,
rs=0x7f7e5fff9c10, which=op_add, oi=0x56094bb8a720, on=<optimized out>) at
backover.c:677
#17 0x000056094a73ceab in over_op_func (op=0x7f7e5fff9c80, rs=<optimized out>,
which=<optimized out>) at backover.c:730
#18 0x00007f7f5361ff6a in accesslog_response (op=<optimized out>, rs=<optimized
out>) at accesslog.c:1877
#19 0x000056094a6dcb98 in slap_response_play (op=op@entry=0x7f7e7410fff0,
rs=rs@entry=0x7f7e5fffa870) at result.c:508
#20 0x000056094a6dd11c in send_ldap_response (op=op@entry=0x7f7e7410fff0,
rs=rs@entry=0x7f7e5fffa870) at result.c:583
#21 0x000056094a6ddd43 in slap_send_ldap_result (op=0x7f7e7410fff0,
rs=0x7f7e5fffa870) at result.c:861
#22 0x000056094a7a86fd in mdb_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at
add.c:435
#23 0x000056094a73cd78 in overlay_op_walk (op=op@entry=0x7f7e7410fff0,
rs=0x7f7e5fffa870, which=op_add, oi=0x56094bb8a900, on=<optimized out>) at
backover.c:677
#24 0x000056094a73ceab in over_op_func (op=0x7f7e7410fff0, rs=<optimized out>,
which=<optimized out>) at backover.c:730
#25 0x000056094a6d32bd in fe_op_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at
add.c:334
#26 0x000056094a6d4139 in do_add (op=0x7f7e7410fff0, rs=0x7f7e5fffa870) at
add.c:194
#27 0x000056094a6cbfc0 in connection_operation (ctx=ctx@entry=0x7f7e5fffaab0,
arg_v=arg_v@entry=0x7f7e7410fff0) at connection.c:1175
#28 0x000056094a6ccdbe in connection_read_thread (ctx=0x7f7e5fffaab0,
argv=0x1a) at connection.c:1311
#29 0x00007f7f5903bead in ldap_int_thread_pool_wrapper (xpool=0x56094bb2a1d0)
at tpool.c:696
#30 0x00007f7f57ae414a in start_thread () from /lib64/libpthread.so.0
#31 0x00007f7f57815f23 in clone () from /lib64/libc.so.6
If we take down the second node, we cannot reproduce the segfaults anymore.
Let me know if we can provide more information (we can't provide the core dump
since it's full of passwords).
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9449] New: When the "lockdetect" is setted in slapd.conf, the db deadlock detected policy is setted incorrected
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9449
Issue ID: 9449
Summary: When the "lockdetect" is setted in slapd.conf, the db
deadlock detected policy is setted incorrected
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: li(a)lihaitao.cn
Target Milestone: ---
I have the "lockdetect random" setted in slapd.conf,the expected deadlock
detected policy is "DB_LOCK_RANDOM" but I got the valude "DB_LOCK_EXPIRE".
After many search of the source file, the lockdetect parse source is found on
openldap-2.4.57\servers\slapd\back-bdb\config.c :Line 894-903
---------------------
case BDB_LOCKD:
rc = verb_to_mask( c->argv[1], bdb_lockd );
if ( BER_BVISNULL(&bdb_lockd[rc].word) ) {
fprintf( stderr, "%s: "
"bad policy (%s) in \"lockDetect <policy>\" line\n",
c->log, c->argv[1] );
return 1;
}
bdb->bi_lock_detect = (u_int32_t)rc;
break;
---------------------
After analyse the verb_to_mask's return value, the "rc" is the index of the
bdb_lockd's setting items. So it can't be passwd to bi_lock_detect.
The right value is The "bdb_lockd[rc].mask".
I think it is a bug, my recommendation fix is like the next.
bdb->bi_lock_detect = (u_int32_t)rc;
->
bdb->bi_lock_detect = bdb_lockd[rc].mask;
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9419] New: Add support for HAProxy proxy protocol v2
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9419
Issue ID: 9419
Summary: Add support for HAProxy proxy protocol v2
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: henson(a)acm.org
Target Milestone: ---
Add support for the HAProxy proxy protocol v2:
https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt
This will allow slapd to receive and act upon client addresses when operating
behind a NAT'ing load balancer or proxy server which would otherwise obscure
the true client address.
Patch will be submitted as a pull request on gitlab.
The submitted pull request is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the pull request were
developed by Paul B. Henson <henson(a)acm.org> based on specifications and
example code provided by HAProxy at the above listed URL. I have not assigned
rights and/or interest in this work to any party.
The modifications to OpenLDAP Software are subject to the following notice:
Copyright 2020 Paul B. Henson
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9474] New: ldap_install_tls() should return meaningful error code
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9474
Issue ID: 9474
Summary: ldap_install_tls() should return meaningful error code
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
The description of my findings (take a note that these are OpenLDAP logs that
happen under the application that uses libldap):
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_write: want=610,
written=610
...
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace:
SSL_connect:SSLv3 flush data
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_read: want=5
error=Interrupted system call
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace:
SSL_connect:error in SSLv3 read finished A
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace:
SSL_connect:error in SSLv3 read finished A
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS: can't connect: .
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection 1
1
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_send_unbind
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ber_flush2: 7 bytes to
sd 23
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01
00 42 00
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_write: want=7,
written=7
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01
01 42 00
[sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection:
actually freed
So, 'error=Interrupted system call' is caught by this:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblda...
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblbe...
It is only the debug message that comes from the caller itself so we can see
what is passed to OpenSSL.
And 'Interrupted system call' is just an EINTR string representation.
What we should do is to catch the error that OpenSSL returns to us after it is
interrupted.
As we can see from the logs:
"libldap: TLS: can't connect: ."
This line returns nothing:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblda...
So 'ld->ld_error' is set to empty value.
If we go deeper into the 'tls_imp->ti_session_errmsg' call we can reach the
point where ERR_peek_error() is called:
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblda...
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblda...
https://git.openldap.org/openldap/openldap/-/blob/master/libraries/liblda...
In the conclusion:
ldap_install_tls() should return meaningful error code that would allow to
figure out a reason for the failure, especially network IO fail due to EITR.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9325] New: Expand SSL test suite for multiple EC support and SAN checks
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9325
Issue ID: 9325
Summary: Expand SSL test suite for multiple EC support and SAN
checks
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to expand the TLS test suite with some additional certs and EC support to
ensure proper testing of issue#9054 and issue#9318
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9477] New: slapd on master branch segfaults at first connection establishment with an LDAP client
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9477
Issue ID: 9477
Summary: slapd on master branch segfaults at first connection
establishment with an LDAP client
Product: OpenLDAP
Version: 2.5
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.coutadeur(a)gmail.com
Target Milestone: ---
Everything is in the title:
slapd on master branch segfaults at first connection establishment with an LDAP
client
slapd-2.5.X-Devel
Compilation options:
./configure --prefix=/usr/local/openldap --libdir=/usr/local/openldap/lib64
--enable-overlays --enable-modules --enable-dynamic=yes --with-tls=openssl
--enable-debug --with-cyrus-sasl --enable-spasswd --enable-ppolicy
--enable-crypt --enable-ldap -enable-slapi --enable-meta --enable-sock
--enable-wrappers --enable-rlookups
using default slapd.conf file:
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/openldap/etc/openldap/schema/core.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /usr/local/openldap/var/run/slapd.pid
argsfile /usr/local/openldap/var/run/slapd.args
# Load dynamic backend modules:
# modulepath /usr/local/openldap/libexec/openldap
# moduleload back_mdb.la
# moduleload back_ldap.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# MDB database definitions
#######################################################################
database mdb
maxsize 1073741824
suffix "dc=my-domain,dc=com"
rootdn "cn=Manager,dc=my-domain,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/openldap/var/openldap-data
# Indices to maintain
index objectClass eq
For information, I also converted this configuration into cn=config with the
same result.
some commands after installation:
mkdir /usr/local/openldap/var/openldap-data
chown -R ldap:ldap /usr/local/openldap
Launch command:
/usr/local/openldap/libexec/slapd -h 'ldap://*:389 ldaps://*:636' -f
/usr/local/openldap/etc/openldap/slapd.conf -u ldap -g ldap -d -1
Establish connection with any client with manager credential on 389 port.
Console output:
6036a1a3 daemon: activity on 1 descriptor
6036a1a3 daemon: activity on:
6036a1a3 slap_listener_activate(7):
6036a1a3 daemon: epoll: listen=7 busy
6036a1a3 daemon: epoll: listen=8 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=9 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=10 active_threads=0 tvp=NULL
6036a1a3 >>> slap_listener(ldap://*:389)
6036a1a3 daemon: accept() = 14
6036a1a3 daemon: activity on 1 descriptor
6036a1a3 daemon: activity on:
6036a1a3 daemon: epoll: listen=7 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=8 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=9 active_threads=0 tvp=NULL
6036a1a3 daemon: epoll: listen=10 active_threads=0 tvp=NULL
6036a1a3 daemon: listen=7, new connection on 14
Erreur de segmentation
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Issue 9433] New: ldapsearch -Z fails to continue when StartTLS fails
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9433
Issue ID: 9433
Summary: ldapsearch -Z fails to continue when StartTLS fails
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
Created attachment 783
--> https://bugs.openldap.org/attachment.cgi?id=783&action=edit
ldapsearch debug log
When -Z is passed to an OpenLDAP utility, it will try to establish a TLS
connection with StartTLS, and in case it fails to do so it should continue
without the TLS layer.
OpenLDAP version:
openldap-2.4.56-4.fc34.x86_64 (but it also doesn't work on older versions too)
How reproducible:
Always
Steps to Reproduce:
1. Run `ldapsearch ...' against a server and see successful operation result.
2. Run `ldapsearch -Z ...' against a server whose certificate is not trusted
(e.g. a hostname mismatch) and observe it fails to connect as in point 1.
Actual results:
~~~
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate
# and it hangs there
~~~
Expected results:
The line
~~~
ldap_result: Can't contact LDAP server (-1)
~~~
is not present and the utility successfully continues with plain LDAP protocol
as expected.
Additional info:
I'm attaching a full debug log (-d -1) to this bug.
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 6 months
[Bug 9199] New: Disable IPv6 makes listener work on IP address but hostname or localhost
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9199
Bug ID: 9199
Summary: Disable IPv6 makes listener work on IP address but
hostname or localhost
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: st-wong(a)cuhk.edu.hk
Target Milestone: ---
Hi,
We're compiling 2.4.49 on CentOS8.
Make test fails at "test000-rootdse" with error Can't contact LDAP server.
Debug log shows error "Address already in use".
We're quite sure the port (9011) is not in use.
Starting slapd with test command verified the error:
../servers/slapd/slapd -f testrun/slapd.1.conf -h ldap://localhost:9011
Found that it's okay to start slapd if listener URL is using IP address
instead.
Checked ldap_url_parse* call may not work as expected with V6 disabled
(configure option --disable-ipv6).
Re-do configuration and make without "--disable-ipv6" works as expected.
Would you help? Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 6 months
[Bug 9192] New: slapo-rwm: assert triggered with invalid UUID filter
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9192
Bug ID: 9192
Summary: slapo-rwm: assert triggered with invalid UUID filter
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
slapo-rwm triggers an assert when a filter with an invalid UUID syntax is used.
For example:
/opt/symas/bin/ldapsearch -x -H ldaps://ldap0.example.com -D
"cn=admin,dc=example,dc=com" -W -b dc=example,dc=com
idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter:
idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com
# requesting: ALL
#
The above search will trigger an assert. Note that idmUUID is a custom
attribute defined as:
# idmUUID
attributetype ( 1.3.6.1.4.1.29179.2.3.3
NAME 'idmUUID'
DESC 'RFC4122 Univeral Unique Identifier for idM'
EQUALITY uuidMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE )
which is using the RFC4530 definition for UUID.
On the slapd side, we see:
#4 0x0000000000468650 in UUIDNormalize (usage=<optimized out>,
syntax=<optimized out>, mr=<optimized out>, val=0x7f1c58003110,
normalized=0x7f1c677fc5c0, ctx=<optimized out>)
at /home/build/sold/openldap/servers/slapd/schema_init.c:3019
No locals.
#5 0x00007f447599c55d in map_attr_value (dc=dc@entry=0x7f1c677fc730,
adp=adp@entry=0x7f1c677fc658, mapped_attr=mapped_attr@entry=0x7f1c677fc660,
value=0x7f1c58003110,
mapped_value=mapped_value@entry=0x7f1c677fc670, memctx=0x7f1c58002810,
remap=0) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:471
vtmp = {bv_len = 0, bv_val = 0x0}
freeval = 0
ad = 0x1947630
mapping = 0x0
#6 0x00007f447599ccc6 in rwm_int_filter_map_rewrite
(op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=0x7f1c58003170,
fstr=fstr@entry=0x7f1c677fc720)
at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:559
i = <optimized out>
p = <optimized out>
ad = 0x1947630
atmp = {bv_len = 7, bv_val = 0x1900bb0 "idmUUID"}
vtmp = {bv_len = 139759712219536, bv_val = 0x7f1c58003240 "c"}
tmp = <optimized out>
ber_bvfalse = {bv_len = 18, bv_val = 0x7f447599f816
"(!(objectClass=*))"}
ber_bvtf_false = {bv_len = 3, bv_val = 0x7f447599f829 "(|)"}
ber_bvtrue = {bv_len = 15, bv_val = 0x7f447599f802 "(objectClass=*)"}
ber_bvtf_true = {bv_len = 3, bv_val = 0x7f447599f812 "(&)"}
ber_bverror = {bv_len = 9, bv_val = 0x7f447599f7f8 "(?=error)"}
ber_bvunknown = {bv_len = 11, bv_val = 0x7f447599f7ec "(?=unknown)"}
ber_bvnone = {bv_len = 8, bv_val = 0x7f447599f82d "(?=none)"}
len = <optimized out>
__PRETTY_FUNCTION__ = "rwm_int_filter_map_rewrite"
#7 0x00007f447599d7a8 in rwm_filter_map_rewrite (op=op@entry=0x7f1c580028f0,
dc=dc@entry=0x7f1c677fc730, f=<optimized out>, fstr=fstr@entry=0x7f1c677fc720)
at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:824
rc = <optimized out>
fdc = <optimized out>
ftmp = {bv_len = 26355712, bv_val = 0x7f4475224500 "\002"}
#8 0x00007f4475999c5b in rwm_op_search (op=0x7f1c580028f0, rs=0x7f1c677fda60)
at /home/build/sold/openldap/servers/slapd/overlays/rwm.c:976
on = 0x1922620
rwmap = 0x1922800
rc = 0
dc = {rwmap = 0x1922800, conn = 0x7f4475224500, ctx = 0x7f447599f090
"searchFilterAttrDN", rs = 0x7f1c677fda60}
fstr = {bv_len = 0, bv_val = 0x0}
f = 0x0
an = 0x0
text = 0x0
roc = 0x7f1c58003218
#9 0x000000000049776a in overlay_op_walk (op=op@entry=0x7f1c580028f0,
rs=rs@entry=0x7f1c677fda60, which=which@entry=op_search, oi=oi@entry=0x1924430,
on=0x1922620)
at /home/build/sold/openldap/servers/slapd/backover.c:671
func = 0x1922678
rc = 32768
#10 0x00000000004978be in over_op_func (op=0x7f1c580028f0, rs=0x7f1c677fda60,
which=op_search) at /home/build/sold/openldap/servers/slapd/backover.c:747
oi = 0x1924430
on = <optimized out>
be = 0x728420 <slap_frontendDB>
db = {bd_info = 0x1922620, bd_self = 0x728420 <slap_frontendDB>,
be_ctrls = "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times>,
be_flags = 768, 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 = 0x18cb690, be_nsuffix = 0x18cb6e0, be_schemadn = {bv_len
= 12, bv_val = 0x1955c20 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val =
0x1955370 "cn=subschema"}, be_rootdn = {
bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0},
be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit =
{lms_t_soft = 3600, lms_t_hard = 0,
lms_s_soft = 50, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr =
0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1925890,
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 = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0,
__owner = 0, __nusers = 0, __kind = 0, __spins = 0,
__elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size =
'\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0,
be_cf_ocs = 0x7200e8 <cf_ocs+392>, be_private = 0x0,
be_next = {stqe_next = 0x18cbcc0}}
sc = <optimized out>
cb = 0x7f1c580031e8
rc = 32768
__PRETTY_FUNCTION__ = "over_op_func"
#11 0x0000000000431006 in do_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at
/home/build/sold/openldap/servers/slapd/search.c:247
base = {bv_len = 14, bv_val = 0x7f1c580025c7 "dc=example,dc=com"}
siz = 0
off = 0
i = <optimized out>
#12 0x000000000042ede5 in connection_operation (ctx=ctx@entry=0x7f1c677fdbd0,
arg_v=arg_v@entry=0x7f1c580028f0) at
/home/build/sold/openldap/servers/slapd/connection.c:1167
rc = 80
cancel = <optimized out>
op = 0x7f1c580028f0
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 = 99
opidx = SLAP_OP_SEARCH
conn = 0x7f4475224500
memctx = 0x7f1c58002810
memctx_null = 0x0
memsiz = 1048576
__PRETTY_FUNCTION__ = "connection_operation"
#13 0x000000000042f0ea in connection_read_thread (ctx=0x7f1c677fdbd0,
argv=0x16) at /home/build/sold/openldap/servers/slapd/connection.c:1314
rc = <optimized out>
cri = {op = 0x7f1c580028f0, func = 0x0, arg = 0x0, ctx = <optimized
out>, nullop = <optimized out>}
s = <optimized out>
#14 0x00007f447a585353 in ldap_int_thread_pool_wrapper (xpool=0x18b1340) at
/home/build/sold/openldap/libraries/libldap_r/tpool.c:963
pq = 0x18b1340
pool = 0x18b1250
task = 0x7f1c68000da0
work_list = <optimized out>
ctx = {ltu_pq = 0x18b1340, ltu_id = 139759972247296, ltu_key =
{{ltk_key = 0x42cbf0 <conn_counter_init>, ltk_data = 0x7f1c58002700, ltk_free =
0x42ccb0 <conn_counter_destroy>}, {
ltk_key = 0x47fef0 <slap_sl_mem_init>, ltk_data = 0x7f1c58002810,
ltk_free = 0x47fdb0 <slap_sl_mem_destroy>}, {ltk_key = 0x1ae4a40, ltk_data =
0x7f1c58102f30,
ltk_free = 0x7f44763ff550 <mdb_reader_free>}, {ltk_key = 0x4416f0
<slap_op_free>, ltk_data = 0x0, ltk_free = 0x441650 <slap_op_q_destroy>},
{ltk_key = 0x0, ltk_data = 0x7f1c58000a80,
ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}
<repeats 27 times>}}
kctx = <optimized out>
keyslot = <optimized out>
hash = <optimized out>
pool_lock = 0
freeme = 0
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#15 0x00007f4478d42ea5 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#16 0x00007f4478a6b8cd in clone () from /lib64/libc.so.6
No symbol table info available.
(gdb)
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 6 months