Re: (ITS#5489) Assert failed in slapd_clr_write()
by rein＠OpenLDAP.org
On Wed, 30 Apr 2008, hyc(a)symas.com wrote:
> rein(a)OpenLDAP.org wrote:
>> We have seen a case where "assert(SLAP_SOCK_IS_ACTIVE(s))" in
>> slapd_clr_write() failed, see the stack trace at the end. The
>> last log message (at loglevel stat) related to the socket was
>> "fd=657 closed (connection lost on write)". The comment where
>> slapd_daemon_task() calls connection_write() makes me believe
>> that slapd_clr_write() should not have use assert here. Remove
>> it or include it as a condition in the following if statement?
>
> How frequently can you reproduce this? I'm tempted to say move the
> assert into the if (SLAP_SOCK_IS_WRITE()) block, and see if it still
> triggers.
This is the only occurrence I have found of this abort, so it is not very
reproduce able :-( But the core shows that SLAP_SOCK_IS_WRITE would be
false (as would SLAP_SOCK_IS_READ), so moving the assert into the if
block should fix this case. And asserting a writeable socket is also
active makes sence to me.
Rein
15 years, 4 months
Re: (ITS#5470) Sporadic failures with RE24
by hyc＠symas.com
luca(a)OpenLDAP.org wrote:
> luca(a)OpenLDAP.org wrote:
>> This is a multi-part message in MIME format.
>> --------------080809000906010300090306
>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> Content-Transfer-Encoding: 7bit
>>
>> Howard Chu wrote:
>>
>>> Thanks. Please try HEAD again.
>>>
>> No way.
>> new testrun directory in
>> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz
>>
>> backtrace attached
>>
> recent commits seem to have fixed it (at least, right now I'm not able
> to reproduce it anymore...)
Right. Confirmed here too; I (temporarily) added an assert(0) to the offending
branch of code to make sure the patch was actually getting hit. It takes a
very particular timing to trigger that code path.
I'm not sure how we can reliably test for this down the road. Perhaps we
should add a "disabled" config keyword for backends and syncrepl consumers, so
that we can start up the individual servers, (which takes an unpredictable
amount of time for each) and then enable various parts in a fixed sequence
(e.g. 1 second sleeps between ldapmodify/enable requests). Even that's hit or
miss, because our test database is so small it's unlikely that we can hit the
window of time on demand.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 4 months
Re: (ITS#5470) Sporadic failures with RE24
by luca＠OpenLDAP.org
luca(a)OpenLDAP.org wrote:
> This is a multi-part message in MIME format.
> --------------080809000906010300090306
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Howard Chu wrote:
>
>> Thanks. Please try HEAD again.
>>
> No way.
> new testrun directory in
> ftp://ftp.sys-net.it/luca_scamoni_its5470_20080430-new.tgz
>
> backtrace attached
>
recent commits seem to have fixed it (at least, right now I'm not able
to reproduce it anymore...)
15 years, 4 months
Potential deadlock in back-monitor cache
by Yin Wang
We are working on a project that could relieve from programmer
the burden of reasoning about deadlocks, races etc.
Our study of the latest OpenLDAP source code shows the following
susceptible to deadlock.
- monitor_cache_get at servers/slapd/back-monitor/cache.c:163
waiting for mp_mutex while holding mi_cache_mutex
- monitor_cache_release at servers/slapd/back-monitor/cache.c:366
waiting for mi_cache_mutex while holding mp_mutex
We have not verified this in production run, which could
be difficult. Any comment would be greatly appreciated.
Yin Wang
15 years, 4 months
Re: (ITS#5491) slapd crashes with ldappasswd
by quanah＠zimbra.com
--On Wednesday, April 30, 2008 10:34 PM +0000 Deepak.Cheema(a)emerson.com
wrote:
> Full_Name: Deepak Cheema
> Version: 2.4.8
> OS: Red Hat Linux 3.0
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (144.189.5.201)
>
>
> Just built, installed openldap 2.4.8 and slapd starts up fine using the
> following
>
> slapd -f slapd.conf -u root
>
> as root user on default port 389
>
> [root@dl2k245 libexec]# ps -ef|grep slapd
> root 15065 1 0 15:31 ? 00:00:00 ./slapd -f
> /dbapps/informatica/l
> dap/etc/openldap/slapd.conf -u root
>
> The process stays up as long as I don't type the ldappasswd command to
> get the encrypted password a new user...
>
> once I type in ldappasswd... this is what happens..
>
> [root@dl2k245 bin]# ldappasswd
> SASL/DIGEST-MD5 authentication started
> Please enter your password:
> ldap_sasl_interactive_bind_s: Can't contact LDAP server
> additional info: SASL(0): successful result: security flags do not
> match
> required
> [root@dl2k245 bin]# ps -ef|grep lapd
> root 15077 14561 0 15:32 pts/3 00:00:00 grep lapd
>
> and the slapd process is no longer there...
>
> Any ideas why it might be happening or how to debug this?
> I tried dbg but it did not tell me much.. maybe I did not use it
> correctly...
>
> Any help is appreciated !
gdb the slapd process, let it run, and then run your ldappasswd command and
see where it is segfaulting. Provide a backtrace, etc.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 4 months
Re: (ITS#5492)
by hyc＠symas.com
huynh.tuan(a)comcast.net wrote:
> --NextPart_Webmail_9m3u9jl4l_14399_1209603117_0
> Content-Type: text/plain
> Content-Transfer-Encoding: 8bit
>
> I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same.
>
> Used crypt to hash password.
DES-based Unix crypt only checks the first 8 characters. As I said, if you
want longer passwords, then your current choice of password hash is no good.
Use some other hash instead. This ITS will be closed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 4 months
(ITS#5492)
by huynh.tuan＠comcast.net
--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same.
Used crypt to hash password.
--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0
Content-Type: text/html
Content-Transfer-Encoding: 8bit
<html><body>
<DIV>
<DIV>I by pass the OS by using JAVA frontend LDAPBrowser v2.8.1, and the symtom appeared to be the same. </DIV>
<DIV> </DIV>
<DIV>Used crypt to hash password.</DIV></DIV></body></html>
--NextPart_Webmail_9m3u9jl4l_14399_1209603117_0--
15 years, 4 months
