(ITS#6376) memleak in 2.3
by mbackes＠symas.com
Full_Name: Matthew Backes
Version: 2.3 only
OS: any
URL:
Submission from: (NULL) (76.88.99.93)
In 2.3, if you have a lot of fast writes such that syncprov_sendresp's
op tmp memory is exhausted and it has resorted to malloc()s AND
controls are asserted, the rs.sr_ctrls free at the end of the function
leaks.
To duplicate: Set up a master and a replica. Do mods like crazy with
some control asserted, e.g. manageDSAIT.
2.4/head handle this differently so it isn't a problem there.
Patch versus OPENLDAP_REL_ENG_2_3:
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/syncprov.c,v
retrieving revision 1.56.2.51
diff -u -u -r1.56.2.51 syncprov.c
--- syncprov.c 9 Jul 2008 20:53:13 -0000 1.56.2.51
+++ syncprov.c 14 Nov 2009 04:14:26 -0000
@@ -803,6 +803,7 @@
}
/* In case someone else freed it already? */
if ( rs.sr_ctrls ) {
+ op->o_tmpfree( rs.sr_ctrls[0]->ldctl_value.bv_val, op->o_tmpmemctx );
op->o_tmpfree( rs.sr_ctrls[0], op->o_tmpmemctx );
rs.sr_ctrls = NULL;
}
--
Matthew Backes
Symas Corporation
mbackes(a)symas.com
13 years, 6 months
Re: ITS#6375
by jose.oliveira＠mailondemand.com.pt
This is a multi-part message in MIME format.
--------------020401060209020404040703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
I am sorry for the mistake and inconvenience.<br>
Thanks for pointing out right direction.<br>
<br>
Best regards,<br>
<br>
<b style=""><span
style="font-size: 8pt; font-family: "Verdana","sans-serif";"><font
style="color: black;" size="+1">José Vicente Fonseca de Oliveira<br>
<img style="width: 125px; height: 108px;" alt="logo mailondemand"
src="cid:part1.09010807.09040809@mailondemand.com.pt"><br>
</font></span></b><span style="font-family: sans-serif; color: black;"></span><a
href="mailto:jose.oliveira@mailondemand.com.pt" target="_blank"><span
style="color: rgb(51, 51, 255);"><span style="font-family: sans-serif;">jose.oliveira(a)mailondemand.com.pt</span></span></a><br
style="font-family: sans-serif; color: black;">
<a href="http://www.mailondemand.com.pt" target="_blank"><span
style="color: rgb(51, 51, 255);"><span style="font-family: sans-serif;">http://www.mailondemand.com.pt</span></span></a><br
style="font-family: sans-serif; color: black;">
<br style="font-family: sans-serif; color: black;">
<span style="font-family: sans-serif; color: black;">Av. Miguel
Bombarda nº133, 7ºD</span><br
style="font-family: sans-serif; color: black;">
<span style="font-family: sans-serif; color: black;">1050-164 Lisboa</span><br
style="font-family: sans-serif; color: black;">
<br style="font-family: sans-serif; color: black;">
<span style="font-family: sans-serif; color: black;">Tel: + 351
925440544</span><br style="font-family: sans-serif; color: black;">
<span style="font-family: sans-serif; color: black;"></span><span
style="font-family: sans-serif;"><span style="color: black;">Skype +
jvf_oliveira</span></span><br>
<br>
Pierangelo Masarati wrote:
<blockquote cite="mid:4AFD95FF.8070209@aero.polimi.it" type="cite">The
ITS is to track software bugs. Please direct software usage questions
to <a class="moz-txt-link-rfc2396E" href="mailto:openldap-solftware@openldap.org"><openldap-solftware(a)openldap.org></a> and software interoperation
questions to <a class="moz-txt-link-rfc2396E" href="mailto:openldap-technical@openldap.org"><openldap-technical(a)openldap.org></a>.
<br>
<br>
This ITS will be closed.
<br>
<br>
p.
<br>
<br>
_________________________
<br>
This email was transferred using an evaluation version
<br>
of AXIGEN Mail Server.
<br>
<br>
<br>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<meta content="text/html; charset=ISO-8859-1" http-equiv="content-type">
<title>JO_Letitwork</title>
<b style=""><span
style="font-size: 8pt; font-family: "Verdana","sans-serif";"></span></b><span
style="font-family: sans-serif;"><span style="color: black;"></span></span><b
style=""><span
style="font-size: 7pt; font-family: "Verdana","sans-serif"; color: rgb(51, 153, 102);"></span></b><b
style=""><span
style="font-size: 7pt; font-family: "Verdana","sans-serif"; color: rgb(51, 153, 102);"
lang="EN-GB"><br>
</span></b></div>
</body>
</html>
<br><br>_________________________<br>This email was transferred using an evaluation version<br>of AXIGEN Mail Server.<br><br>
--------------020401060209020404040703
Content-Type: image/jpeg;
name="modlogo_small.jpg"
Content-Transfer-Encoding: base64
Content-ID: <part1.09010807.09040809(a)mailondemand.com.pt>
Content-Disposition: inline;
filename="modlogo_small.jpg"
/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAUDBAQEAwUEBAQFBQUGBwwIBwcHBw8LCwkMEQ8S
EhEPERETFhwXExQaFRERGCEYGh0dHx8fExciJCIeJBweHx7/2wBDAQUFBQcGBw4ICA4eFBEU
Hh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh4eHh7/wAAR
CABsAH0DASIAAhEBAxEB/8QAHAAAAAcBAQAAAAAAAAAAAAAAAAECAwQFBgcI/8QANxAAAQMD
AwIDBgUDBAMAAAAAAQIDBAAFEQYSIRMxByJRFDJBYXGBI0KRobFSctEVM0PBFjRj/8QAFAEB
AAAAAAAAAAAAAAAAAAAAAP/EABQRAQAAAAAAAAAAAAAAAAAAAAD/2gAMAwEAAhEDEQA/APZd
ChQoBQos/Ki3UCqFNGQ1uKd6cjuM0sLSRkEGgVQot1FuGaBVCi3fKjBzQChQoUAoj3zR0KAg
aOiPHNGDQCklXf5UqknuaCI/LUlvdHZLxzykKwRVLOmz1FSSh1tBOQNhyPuKsXsoeUUfA+Ye
opaFhaeDgenpQZpTylKJWrzH1V/mnG3XRyhxz7Z/6rRqQ0oAKSk/Uc0yu3wlqyqOjJ+IGKCo
TPlo49oV+v8AkVIRdpYI8yVj5p/xUpVojf8AG68j5b8j96Ycsqtx2voV/e3/AIoHU3p1PvsJ
P0JH8in2r4yfeZWPoQarlWqWn3Etq/scI/Y005DmI9+M6oeuAqgvkXaGrupSfqmnm50VZwl5
B+9ZUjYcLBb/ALkKTS0HdwCFfRYV/NBrA6k9lJP3pQVmsXOnIhIUOOpgZyMYHrwavNJOqfsz
T6lFRcJOSfnQXVFg0dCgFFjnvR0KCrleSQv9qZPHmT3/AJp25cSftUfefWgfbdCxkdx3HpTu
7jNRFA53oICv5pbLoWnnj1FBJCsjmnAeKjbh8KWFHsDQSEq+dGD8QTUZbqGk7nFgAdyTTXXe
e/2ElCf61D+BQS33W205dIAPrUN1lMn3YzTaMZ3qTyfoKdYYSlW9eVr/AKlc0uY504j6z2Q2
on9KDkd5uBU44hBIAJH7mup6Oa6Om4CTnJaBP35riLznVd79zx9zXerS30bZGZ+KGkj9qCbQ
oUKDO6p1tpbTExqHfbyxCkvR1yGmVJUpbjaFJSpSUpBKsFQyBzjJ7AkR7Z4g6Nud2YtVs1DC
mS5DPWYQ0oqS6naFeVeNqiEqBKQcgHJFV9xs053xvtOpVRErtcXTkyGqQVIyh9yTGUlITndy
htzkDHGCeQDz7SujtQWvSvhbAftiI79hny3rkhLzR6CXGJSQrKVYXlbqPdyfNk9jgNdfvEDq
3Z6NYNPzryiM6Y70lEhiOx1U+82hTq09RQwc7QQCCM8Go7niBDVpOTeo0Uofiy4sWRDnPBhT
Snnm20kqAUCCHApJTlK+ACM5HFLlCjt3kQLzD07NkQrPKtJh3uYmN7I8t9biZ7O9KgsOJKcq
RhQKQMjBxorBpK+XbwYjIhm2zphj2GCy3AmJcbW1b5TJddLitqSSEOqwOMJABUTQdh0lqQX6
4akiGH7ObJeF2zd1N3W2sMu9TGBt/wB7G3n3c55wE3DXGkrfqAWOZfobNyK0NlpW7CFr9xCl
42oUrIwlRBORiq3w/tNxtV31rInx+i3c9RuToZ3pV1GTFjNhXBO3zNrGDg8dsEVi77pfVy7f
q3SMTTzUuLqK6Klt3tU1pLcZDnT3dRsnqlxvYdm1KgcJ5FB0O7+IuibPdJNqumo4cSbFcbak
tOBX4ClpSpG8gYQCFpwokDnGc1orjLTFhuynHW2GWUlx111QSlCAMlRJ4AA5zXLL5o69SbZ4
xstW1Lr2pYiWrSVOtgylJtaGBklXkw6FDz7fXtzWp1vp6fqLwln6YZcaanybWlhPWVlHUCU+
VRGfKSnaSM8E96CNpzxF07ftcw9P2SS1c0yLXIuLkvepBaDbjKEp6akjKVB0kLBx5eM5yNBp
/W2k79dja7NfIsyYEqWltG4dRKThSmyQA4ASMlBIFc8cs+r9Ua7RdZ+lHNMw/wDxWdaVPLnx
33EvvOMFOA0o+QBCik9+DkJyAS8K9I3a33fTov1i1GhyxMltubIv7D8FKun0yWWknqYUM8KS
nHzxQbWD4reHk1tLkTVlvdQtj2hsgL/FRlI8mU+dWVJBSnKgSBinNR6406jw9c1JDuCZ8KYh
TEIxUla5Lp3J6aE99wKVZBxt2qzjBrC6F0Lf7ZZvBiNOs7bTmmESv9WT1mlezKXDdQkjCjvJ
dUnlG7nk8DNU2qrFetM6Tud0ucZyNETqW9v72lJdMePNWroSsIJwBkZHdIcJIGDQZ+26s2XS
Gi72WVbozshLXtC32XUoO5I/ECFko5IBJGBkZxXoG7eI2h7HOetd11DEizIgbElpSVEshaQU
qWQCEpI/McD51420rpw3K+afs9vZ0tDcetki1SZEW4BxcjqJQDI2pRlSsJWoZ5yeSBivSj2m
ru8fFFSLehZv8BqPblF1vMgpiKbKTk+UbzjzYHOe3NB0TUWttKaemxIV5vkSHIloLrSFEn8M
EAuKwDsbyR51YT86Lwz1MdZ6AseqzB9g/wBVhok+zdXqdLcM7d2Bn64Fc8tdk1fp3US7lE0u
3qFF401b7W8lyay37A/HS6FJc3nzMK62SW96spPlORWx8D7Jc9N+EOlrDeo3stxgW1piSz1E
r2LSORuSSk/UEig0cg5SaqZ5wDjvVxIAKTVZKa3ZyKDB6otMW6Ae3Q48nZ7nWaC9v0yOKz64
06CoKhSXmMDACVHH6dq6LNiBWeKqZlvBHYUGaias1BCwmQGpaB/WMH9RV3A1/BXhM6K9HV8S
BuFQ5NrB7Jqsk2gEny0HQbdf7RPA9mnsLUfylWD+hq0QoiuMP2jBKgnB+XFORJd9t3/qT5CQ
PyqVuH6Gg7MlfPejJwdzf3Fcyha6vDGBNiMygO5RlBP/AFWgt+u7NIUEyA9DX/8AROR+ooNg
leeQeKzviY9s0m8M4K1oT+9WMS4QpWFw5TT2e4SofxWb8V5ATp9htIV+LIAGB6A0HO9MoiwL
63Ihw4zasnqltsJJ+pA5rsFonIkISoHFcx09bHdyVrB3HGeK3tmjrbSO9Bsoi8gYqe2Vbe9U
9vztHNW7OdnagQ63x2qI80DxirMjNNONjvQUz0cEcioL0UHvV+40DTDkfPwFBm3oXHaojsAH
4VqnIwNMKij0oMg9bQfy/tUR21A/l/atouIk00qCPSgw7tnTn3f2plVhSr/jz9q3nsA9KUiA
PSgwcXTQDgUjc2fVPBrRMWcOMIalLXICFbkhw5wa0TMNKfhzUhEYA9qCni2uO37rYFWkaClP
apTbAB7CpTLWKBMeOE9hUwBIGKShO0c0a/hmgXREZo6FAkoBpBbBp2kUDSmvjikKaHfFScmj
wKCF0BntRFgH4VO2ihtFBA9nHpSkx0/Gpu0UNooIyY4+ApYZA+FOng4FDJ9aBAbA+FObR8BS
aWKBOPnSXCvjakH6mnD2pIoP/9k=
--------------020401060209020404040703--
13 years, 6 months
Re: (ITS#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com
pitpalme(a)gmail.com wrote:
> masarati(a)aero.polimi.it wrote:
>
>> pitpalme(a)gmail.com wrote:
>>
>>> I do see attributes reflecting state after "modify" (which changes
>>> "sn" attribute).
>>> Where exactly should I expect to see a note about "glue state"?
>>> Is output from "-d Any" helpful to figure what's going on (or wrong)?
>>
>> My understanding of your previous message was that you got a positive
>> result from delete, but an "Already exists" from a subsequent add.
>
> That=92s korrekt.
>
>> I inferred that you checked about the existence of the object and =20
>> you got
>> a negative result.
>
> In my current test scenario I do not check.
> I assume a non-error on =84delete=93 in fact =84deletes=93, so I just =
> check if =20
> response
> code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91).
>
>> Apparently, my guess was wrong. In that case, you probably hit
>> ITS#6097 <http://www.openldap.org/its?findid=3D6097>.
>
> *hmmm* Good idea, thanks.
> But after reading ITS description I don=92t think it=92s what troubles =
> me.
> We don=92t actually neither have =84multi master mode=93, but =84mirror =
> mode=93 =20
> and writes are done only on exactly one server, so there should not be =20=
>
> a problem with second server producing a concurrent write/modify.
> I=92d expect the delete to be correctly propagated, but I can=92t check =
> it =20
> is is, simply because I have to little knowledge to read debug log =20
> correctly.
> =97
Paste the debug log somewhere we can see it then. Might as well use debug
level -1 while executing this sequence. And provide the debug output from both
servers.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 6 months
Re: (ITS#6361) Failed assertion in slapd when running on OpenWRT/glibc
by hyc＠symas.com
mike(a)flyn.org wrote:
> Yes, I have just been able to recreate this in 2.4.19. The line in
> daemon.c at which the assertion occurs in this version is 994.
>
> I have also seen:
>
> ldap_write: want=22 error=Broken pipe
> ...
> slapd: connection.c:786: connection_closing: Assertion 'c->c_struct_state
> == SLAP_C_USED' failed
Please provide stack traces for each of these assertions. In this case it
sounds like connection_closing() got called multiple times for the same
connection, after it had already been fully closed. A trace would help confirm
that.
> One things to note is that, in addition to being on MIPS32, my platform
> has only 32MB of memory. I also have a swap file that is 64MB.
In such an environment you won't have enough memory for more than 1 or 2
server threads. Have you already configured this?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 6 months
Re: (ITS#6365) Bad slapcat output when slapd running
by hyc＠symas.com
apm(a)mutex.dk wrote:
> Pierangelo Masarati wrote:
>> You appear to be using back-hdb.
>
> Yes.
>
>> My guess is that if this can fail, e.g. because entries are being
>> sync'ed out of order, the DN does not get fixed. If this is the case (I
>> couldn't inspect code deep enough to make sure), I'd expect that the DN
>> get fixed anyway, though, because missing entries should exist as "glue"
>> objects.
>
> yes. But if you plan to use slapcat as a backup mechanism, then it's
> still a problem.
Sounds like a low priority issue at best. Taking backups of a replica while it
is initializing is pointless, just take a backup of the provider instead.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years, 6 months
Re: (ITS#6365) Bad slapcat output when slapd running
by apm＠mutex.dk
Pierangelo Masarati wrote:
> You appear to be using back-hdb.
Yes.
> My guess is that if this can fail, e.g. because entries are being
> sync'ed out of order, the DN does not get fixed. If this is the case (I
> couldn't inspect code deep enough to make sure), I'd expect that the DN
> get fixed anyway, though, because missing entries should exist as "glue"
> objects.
yes. But if you plan to use slapcat as a backup mechanism, then it's
still a problem.
/Peter
13 years, 6 months
Re: (ITS#6365) Bad slapcat output when slapd running
by masarati＠aero.polimi.it
apm(a)mutex.dk wrote:
> Full_Name: Peter Mogensen
> Version: 2.4.19
> OS: Debian Lenny
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (95.166.36.16)
>
>
> Using openldap 2.4.17 and 2.4.19 linked with libdb4.6 and libdb4.8 in a
> mirrormode setup:
>
> * Load the database with slapadd on server-1, start server-1
> The LDIF being loaded is generated with slapcat from a slapd 2.3.30-5+etch2
> Running on Debian Etch. I have no reason to suspect that it is not loaded
> correctly into server1
>
> * Start server-2 and monitor the progress of replication with slapcat, for
> example:
>
> # for ((I=1;I<=20;I++)); do slapcat > out-$I; done
>
> * Look at the output:
>
> # for ((I=1;I<=20;I++)); do wc -l out-$I; done
>
> I would expect the generated files to be strictly increasing in size.
> However, some times there's a file which is smaller than the previous.
> In it I see LDIF entries like this:
>
> dn:
> objectClass: top
> objectClass: NamedObject
> objectClass: simpleSecurityObject
> uid: rieke
> userPassword:: e1NBU0x.....
> structuralObjectClass: NamedObject
> entryUUID: e46b680e-e5f5-102b-93c9-79162adc1d46
> creatorsName: dc=admin,dc=example,dc=com
> createTimestamp: 20070823185333Z
> entryCSN: 20070823185333.000000Z#000002#000#000000
> modifiersName: dc=admin,dc=example,dc=com
> modifyTimestamp: 20070823185333Z
>
> ... with an empty DN line.
You appear to be using back-hdb. I note that in bdb_tool_entry_get()
there is code specific to back-hdb that tries to lookup the parent of
the current entry and, if found, "fixes" its DN.
My guess is that if this can fail, e.g. because entries are being
sync'ed out of order, the DN does not get fixed. If this is the case (I
couldn't inspect code deep enough to make sure), I'd expect that the DN
get fixed anyway, though, because missing entries should exist as "glue"
objects.
I apologize for the rather incomplete analysis, I can't dig further
right now. I hope this provides some hint to others, unless completely
wrong.
p.
13 years, 6 months
ITS#6375
by masarati＠aero.polimi.it
The ITS is to track software bugs. Please direct software usage
questions to <openldap-solftware(a)openldap.org> and software
interoperation questions to <openldap-technical(a)openldap.org>.
This ITS will be closed.
p.
13 years, 6 months
(ITS#6375) Master Replica Synchronization
by jose.oliveira＠mailondemand.com.pt
Full_Name: Jose Vicente Fonseca de Oliveira
Version: 2.4.11-1
OS: Debian 5.03
URL: ftp://mailondemand.com.pt
Submission from: (NULL) (81.193.248.175)
Dear Team,
We have a PineApp antispam appliance that can authenticate users with our LDAP
master server but cannot authenticate users with our LDAP replica server. For us
everything seems OK but PineApp appliance just can't authenticate with our
replica.
PineApp refuses to give us further help saying that something is wrong in LDAP
replication. Please, could you help us with that issue: the replica has the same
information that master server has?
We thank OpenLDAP Team in advance.
Best regards,
Jose Oliveira
13 years, 6 months
