Re: (ITS#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> Apparently, the cache lru is not initialized. Backtrace:
>
works for me, now. Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 4 months
Re: (ITS#4783) ldap_sasl_bind() is not asynchronous
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> fcusack(a)fcusack.com wrote:
>> But still you can do the bind async, and just close the fd on the client
>> side on timeout. I don't see why connect() timeout can't be handled
>> the same way. (ignoring the problem that there is no API call AFAICT
>> to just drop the connection)
>>
> I'll note that there's been some interest in that area --- I loosely
> have the same need (see
> <http://www.openldap.org/lists/openldap-devel/200611/msg00000.html>) but
> unfortunately it's not in my priority list, considering that it might
> have relevant impact on the client library.
Eventually, this got on top of my priority list, and it's now
implemented in HEAD. One needs to:
- set LDAP_OPT_NETWORK_TIMEOUT to a value greater than 0
- set LDAP_OPT_CONNECT_ASYNC to TRUE
- perform the first operation asynchronously (e.g. ldap_sasl_bind(3))
the library call might return LDAP_X_CONNECTING if poll(2)'ing after
connect(2) didn't succeed yet and LDAP_OPT_NETWORK_TIMEOUT didn't expire
yet. In that case, the client should resubmit the request until it
either succeeds or LDAP_OPT_NETWORK_TIMEOUT expires.
Note that, right now, there's no means to set LDAP_OPT_CONNECT_ASYNC
other than via ldap_set_option(3), and none is foreseen, because only
specially crafted clients would be able to handle LDAP_X_CONNECTING
appropriately.
Please test.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 4 months
(ITS#4797) back-bdb crashes during test34-translucent
by ando＠sys-net.it
Full_Name: Pierangelo Masarati
Version: HEAD
OS: Linux SuSE 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.175.154.35)
Submitted by: ando
Apparently, the cache lru is not initialized. Backtrace:
masarati@xxx:~/yyy/ldap-devel/tests> gdb ../servers/slapd/slapd core.1900
GNU gdb 6.3
<snip>
#0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50,
e=0x8efbc0, decr=1) at cache.c:1240
1240 LRU_DEL( cache, e );
(gdb) bt
#0 0x00000000004f9e13 in bdb_cache_delete_internal (cache=0x817b50,
e=0x8efbc0, decr=1) at cache.c:1240
#1 0x00000000004f9bdf in bdb_cache_delete (bdb=0x817af0, e=0x8c5bf8,
locker=2147483683, lock=0x41801820) at cache.c:1155
#2 0x00000000004fde8f in bdb_delete (op=0x8d94e0, rs=0x41801d50)
at delete.c:520
#3 0x00000000004b0011 in overlay_op_walk (op=0x8d94e0, rs=0x41801d50,
which=op_delete, oi=0x819310, on=0x0) at backover.c:507
#4 0x00000000004b0215 in over_op_func (op=0x8d94e0, rs=0x41801d50,
which=op_delete) at backover.c:559
#5 0x00000000004b035f in over_op_delete (op=0x8d94e0, rs=0x41801d50)
at backover.c:611
#6 0x00000000004580ca in fe_op_delete (op=0x8d94e0, rs=0x41801d50)
at delete.c:180
#7 0x0000000000457cbc in do_delete (op=0x8d94e0, rs=0x41801d50) at delete.c:91
#8 0x0000000000438689 in connection_operation (ctx=0x41801e90, arg_v=0x8d94e0)
at connection.c:1128
#9 0x0000000000438b6c in connection_read_thread (ctx=0x41801e90, argv=0xd)
at connection.c:1256
#10 0x0000000000592587 in ldap_int_thread_pool_wrapper (xpool=0x7d99a0)
at tpool.c:704
#11 0x00002aaaab0befa5 in start_thread () from /lib64/tls/libpthread.so.0
#12 0x00002aaaab28acb2 in clone () from /lib64/tls/libc.so.6
#13 0x0000000000000000 in ?? ()
<snip>
(gdb) p cache[0]
$1 = {c_eifree = 0x0, c_idtree = 0x8ebaa0, c_lruhead = 0x0, c_lrutail = 0x0,
c_dntree = {bei_parent = 0x0, bei_id = 0, bei_lockpad = 0 '\0',
bei_state = 128, bei_finders = 0, bei_nrdn = {bv_len = 0, bv_val = 0x0},
bei_e = 0x0, bei_kids = 0x8ec040, bei_kids_mutex = {__m_reserved = 0,
__m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0,
__spinlock = 0}}, bei_lrunext = 0x0, bei_lruprev = 0x0},
c_maxsize = 1000, c_cursize = 4, c_minfree = 1, c_eiused = 3, c_leaves = 1,
c_purging = 0, c_locker = 6, c_rwlock = 0x817db0, c_lru_mutex = {
__m_reserved = 1, __m_count = 0, __m_owner = 0x100000771, __m_kind = 0,
__m_lock = {__status = 0, __spinlock = 0}}, c_count_mutex = {
__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__status = 0, __spinlock = 0}}, c_eifree_mutex = {
__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0,
__m_lock = {__status = 0, __spinlock = 0}}}
(gdb) p e[0]
$2 = {bei_parent = 0x8e2cc0, bei_id = 7, bei_lockpad = 0 '\0',
bei_state = 139, bei_finders = 0, bei_nrdn = {bv_len = 11,
bv_val = 0x8e26f0 "uid=someguy"}, bei_e = 0x8c5bf8, bei_kids = 0x0,
bei_kids_mutex = {__m_reserved = 1, __m_count = 0, __m_owner = 0x100000771,
__m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}},
bei_lrunext = 0x0, bei_lruprev = 0x0}
16 years, 4 months
Re: (ITS#4494) connections are not asynchrounous
by ando＠sys-net.it
lrm(a)interlinknetworks.com wrote:
> I have already tried this. It does not have any affect on SSL connection
> negotitation.
>
> There is a very interseting comment in the code which indicates someone was
> aware of the problem. From the 2.3.20 source distribution, file
> libraries/libldap/tls.c (line 1445):
>
> /*
> * Fortunately, the lib uses blocking io...
> */
> if ( ldap_int_tls_connect( ld, conn ) < 0 ) {
> ld->ld_errno = LDAP_CONNECT_ERROR;
> return (ld->ld_errno);
> }
>
> And in ldap_int_tls_connect(), there is a call to SSL_connect( ssl ) that has no
> provision for asynchronous operation. There is no setting of the non-blocking
> option that I can find in this code sequence.
>
>
> To reproduce the problem, simply point your ldaps: URL to a TCP server port that
> accepts connections, and does nothing with them. The LDAP client will hang
> forever (or until the server ephemeral port is closed).
Is it an option for you to use Start TLS instead of ldaps? In this
case, code in right HEAD should fix all non-blocking issues, as soon as
you specify a network timeout and LDAP_OPT_CONNECT_ASYNC (undocumented
yet, it's been committed just hours ago).
The usage I suggest is to set LDAP_OPT_NETWORK_TIMEOUT to a positive
value; then set LDAP_OPT_CONNECT_ASYNC to TRUE before performing the
first operation, and reset it to FALSE after the first operation
succeeds. In your case, the first operation would be ldap_start_tls[_s](3).
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 4 months
Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by ando＠sys-net.it
robb(a)wtg.cw.com wrote:
> Pierangelo Masarati wrote:
>> In any case, since the behavior you report is very data and meta-data
>> dependent, you don't provide enough info for debugging, and at a very
>> first glance this is not indicative of a software bug.
>
> Pierangelo,
>
> the problem is indeed with the meta-data:
>
> the object at the root of the sql tree "dc=sql,dc=example,dc=org" was
> defined purely as dcObject, it needs a structural objectClass in order
> to be valid.
>
> If we define it as an organizationalUnit and dcObject (using
> ldap_entry_objclasses) then all works as expected.
>
> Oddly doing the opposite doesn't seem to work.
Because somewhere a constraint stepped in, which requires objectClasses
in ldap_objectclasses to be structural; it makes sense, all in all.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 4 months
Re: (ITS#4786) back-sql searching with dn attribute selected causes object class violation
by robb＠wtg.cw.com
Pierangelo Masarati wrote:
> In any case, since the behavior you report is very data and meta-data
> dependent, you don't provide enough info for debugging, and at a very
> first glance this is not indicative of a software bug.
Pierangelo,
the problem is indeed with the meta-data:
the object at the root of the sql tree "dc=sql,dc=example,dc=org" was
defined purely as dcObject, it needs a structural objectClass in order
to be valid.
If we define it as an organizationalUnit and dcObject (using
ldap_entry_objclasses) then all works as expected.
Oddly doing the opposite doesn't seem to work.
Many thanks,
Rob
--
Robert Brooks, Network Manager, Cable & Wireless UK
<robb(a)wtg.cw.com> http://wtg.cw.com/
Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601
- "What was your username again?" - BOFH -
16 years, 4 months
