michael.vishchers(a)7p-group.com wrote:
> --_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_
> Content-Type: multipart/alternative;
> boundary="_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_"
>
> --_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_
> Content-Type: text/plain; charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> It is not the client loop that is multithreading but the ldap server.
Thanks for clarifying.
>
> And it is not a misuse of the API but a problem that may be raised by day t=
> o day network problems.
>
> I've boiled down the problem to a few simple configurations that work (or b=
> etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup =
> with start script and testclient is attached. It should be sufficient to re=
> produce the fault.
>
> The problem occurs only if we use session variable substitution in the rwm =
> overlay, and only if a search is *immediately* (e.g. caused by network loss=
> and client timeout) followed by an unbind.
Yes, your test config shows that the problem is that rwm_conn_destroy frees
the session context while rwm_op_search is using it. Seems like the rwm
overlay is not doing reference counting properly.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_
Content-Type: multipart/alternative;
boundary="_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_"
--_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
It is not the client loop that is multithreading but the ldap server.
And it is not a misuse of the API but a problem that may be raised by day t=
o day network problems.
I've boiled down the problem to a few simple configurations that work (or b=
etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup =
with start script and testclient is attached. It should be sufficient to re=
produce the fault.
The problem occurs only if we use session variable substitution in the rwm =
overlay, and only if a search is *immediately* (e.g. caused by network loss=
and client timeout) followed by an unbind.
Mit freundlichen Gr=FC=DFen / Kind regards
Michael Vishchers
Senior System Engineer
7P Solutions & Consulting AG
Calor-Emag-Stra=DFe 1
40878 Ratingen
Phone : +49-2102-5354-356
Fax : +49-2102-5354-111
Email : michael.vishchers(a)7p-group.com<mailto://michael.vishchers@7P-Grou=
p.com>
Home : www.7p-group.com<http://www.7P-Group.com>
Sitz der Gesellschaft: K=F6ln
Registriergericht: Amtsgericht K=F6ln
Handelsregister: HRB 32361
Aufsichtsratsvorsitzender: Dr. Kai H=F6hmann
Vorstand: Jens Harig (Vorsitzender), Dr. Joachim Philippi
USt-ID-Nr.: DE197820124
Steuer-Nr.: 215/5917/1764
Eine Bitte: Denken Sie an Ihre Umwelt, bevor Sie diese E-Mail ausdrucken!
P Please consider the environment before printing this e-mail
Der Inhalt dieser e-Mail ist ausschlie=DFlich f=FCr den bezeichneten Adress=
aten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder d=
essen Vertreter sein sollten, beachten Sie bitte, dass jede Form der Ver=F6=
ffentlichung, Vervielf=E4ltigung oder Weitergabe des Inhalts dieser e-Mail =
unzul=E4ssig ist. Wir bitten Sie sofort den Absender zu informieren und die=
E-mail zu l=F6schen.
The information contained in this e-mail is intended solely for the address=
ee. Access to this e-mail by anyone else is unauthorized. If you are not th=
e intended recipient, any form of disclosure, reproduction, distribution or=
any action taken or refrained from in reliance on it, is prohibited and ma=
y be unlawful. Please notify the sender immediately and destroy this e-mail=
.
--_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html dir=3D"ltr">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style id=3D"owaParaStyle" type=3D"text/css">P {margin-top:0;margin-bottom:=
0;}</style>
</head>
<body ocsi=3D"0" fpstyle=3D"1">
<div style=3D"direction: ltr;font-family: Tahoma;color: #000000;font-size: =
10pt;">It is not the client loop that is multithreading but the ldap server=
.<br>
<br>
And it is not a misuse of the API but a problem that may be raised by day t=
o day network problems.<br>
<br>
I've boiled down the problem to a few simple configurations that work (or b=
etter, fail ;-) with both 2.4.23 and 2.4.36. A tgz file containing a setup =
with start script and testclient is attached. It should be sufficient to re=
produce the fault.
<br>
<br>
The problem occurs only if we use session variable substitution in the rwm =
overlay, and only if a search is *immediately* (e.g. caused by network loss=
and client timeout) followed by an unbind.<br>
<div><br>
<div style=3D"font-family: Tahoma; font-size: 13px;">
<div style=3D"font-family: Arial; font-size: 13px;">Mit freundlichen Gr=FC=
=DFen / Kind regards<br>
Michael Vishchers<br>
Senior System Engineer<br>
<br>
7P Solutions & Consulting AG<br>
Calor-Emag-Stra=DFe 1<br>
40878 Ratingen<br>
<br>
Phone : +49-2102-5354-356<br>
Fax : +49-2102-5354-111<br>
Email : <a href=3D"mailto://michael.vishchers@7P-Group.com" tab=
index=3D"0">michael.vishchers(a)7p-group.com</a><br>
Home : <a href=3D"http://www.7P-Group.com" tabindex=3D"0">www.7=p-group.com</a><br>
<br>
<p class=3D"MsoNormal" style=3D"margin-bottom: 12pt; color: rgb(153, 153, 1=
53);"><font style=3D"color: rgb(192, 192, 192);" size=3D"1"><span style=3D"=
font-size: 10pt; font-family: "Arial Narrow","sans-serif&quo=
t;;">Sitz der Gesellschaft: K=F6ln<br>
Registriergericht: Amtsgericht K=F6ln<br>
Handelsregister: HRB 32361<br>
Aufsichtsratsvorsitzender: Dr. Kai H=F6hmann<br>
Vorstand: Jens Harig (Vorsitzender), Dr. Joachim Philippi<br>
USt-ID-Nr.: DE197820124<br>
Steuer-Nr.: 215/5917/1764</span></font><b><i><span style=3D""></span></i></=
b></p>
<p class=3D"MsoNormalCxSpMiddle" style=3D"margin-bottom: 12pt; color: rgb(1=
53, 153, 153);">
<b><i><span style=3D"font-size: 9.5pt; font-family: "Arial Narrow"=
;,"sans-serif";">Eine Bitte: Denken Sie an Ihre Umwelt, bevor Sie=
diese E-Mail ausdrucken!</span></i></b><b><span style=3D"font-size: 9.5pt;=
font-family: "Arial Narrow","sans-serif";">
</span></b><span style=3D"font-size: 9.5pt;"></span></p>
<p class=3D"MsoNormalCxSpMiddle" style=3D"margin-bottom: 12pt; color: rgb(1=
53, 153, 153);">
<b><i><span style=3D"font-size: 28pt; font-family: Webdings;">P</span></i><=
/b><i><span style=3D"font-size: 14pt;">
</span></i><i><span style=3D"font-size: 9.5pt; font-family: "Arial Nar=
row","sans-serif";" lang=3D"EN-US">Please consider the envir=
onment before printing this e-mail</span></i></p>
<p class=3D"MsoNormal" style=3D"color: rgb(153, 153, 153);"><span style=3D"=
font-size: 8pt; font-family: "Arial Narrow","sans-serif"=
;;">Der Inhalt dieser e-Mail ist ausschlie=DFlich f=FCr den bezeichneten Ad=
ressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser
e-Mail oder dessen Vertreter sein sollten, beachten Sie bitte, dass jede F=
orm der Ver=F6ffentlichung, Vervielf=E4ltigung oder Weitergabe des Inhalts =
dieser e-Mail unzul=E4ssig ist. Wir bitten Sie sofort den Absender zu infor=
mieren und die E-mail zu l=F6schen.<br>
The information contained in this e-mail is intended solely for the address=
ee. Access to this e-mail by anyone else is unauthorized. If you are not th=
e intended recipient, any form of disclosure, reproduction, distribution or=
any action taken or refrained from
in reliance on it, is prohibited and may be unlawful. Please notify the se=
nder immediately and destroy this e-mail.</span></p>
<p class=3D"MsoNormal"> </p>
</div>
</div>
</div>
</div>
</body>
</html>
--_000_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_--
--_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_
Content-Type: application/x-compressed-tar; name="test_scenario.tgz"
Content-Description: test_scenario.tgz
Content-Disposition: attachment; filename="test_scenario.tgz"; size=2305;
creation-date="Tue, 15 Oct 2013 11:09:38 GMT";
modification-date="Tue, 15 Oct 2013 11:09:38 GMT"
Content-Transfer-Encoding: base64
H4sIAFX9XFIAA+1a3XPbuBG33UxnjM70vS+dPVqXyIk+SOrrKltu0sTpeTrn3FzSt8y5EAlZbEiA
BcjIas4zfeu/3QVI6stO3On5lLaHnz22uAR3F4vFYnepjKnsQgWMUxmJ9s5PAhcx6PXMf8Tmf/PZ
831/4A363U53x/X8rt/fgd5Po846cpVRCbAjhcg+Ne6u+/+jyNbWX8U0Df1WIPjkHmXoBe53ux9d
/x7eK9e/O/A7uP7dbr+7A+496vBR/MzXP+JBnIcM2iwL2iJlPA5p2lbBlCW0HQjJWsVnEovLmL1n
MaC9MgVccEayqWQ0VNDxCQlpRsdUMUhYRonKJ5PoChwx0g7mkJBNaB5nTbT1JcuKp0MeUOTdzLIY
wkjRccxCgjekRBkiJZKNIx42qWrmisn9OVNERRy1aKJ/ctDXeKOZsSQVksr5ksxZNhPyXTOLEiby
DDxCchntO3puw3bb8wctF3+8od/56ndtkY9oo1IUpc5klLFTfhlxBoJXhOeCZ+wqg3ImFfm7PGbg
1FtPDn/fWGFUcwCcmueAM3TI517jT2F9/3sX2uQtSWf3KeOu/e92F/Hf73V8vf/9vm/3/zbg/nZv
d/cvv9nb/cWDXwd8pGdZuvA/HvyfTtliBev7PwtS3PutNL5XGXfkf34X9/xi/w86xf4f2P2/DRx8
0c6VbGPYb6dMxtCc6UMVD2AZBdkRwYN8DPqQR7eADwQQyRzqtQmnCTuEETy9ODLUWAQ0hlq7uNKJ
BNTPzhvOcTHUOTyqHq5Jlo2Oz85PCkoQC5R3dl5c4b1ccjPmiFwTo8vZq+HwtQjeaRI5+Bjg+dfP
zv94Cl+ffndKiJYTpSPHqDUVeLIfGRpmCtkID/2jYog+7XAS1QTrzvIA1BrrIYpRGUzXBvkXBbEa
ZsZh8sNDwXFgSoN3UH/0/KtHDbK/r2flXnXchnvl9pcE19cET//pLKk9d0H1G8YgFfucl7pW3AcV
94p5b3G9xhsONKUD0QQqFSOdvmWAtg2rR7rmEVdLUyxmQQav37x49ec3R1D7AYV6hRZPlVkGVfpF
EDPK83TpF085my2GaNoEE0jM8cyyK6hXzx/iI/tcZ1Oo1Rc6pcJcK8QhR2QfKfUl6bimTszopauY
UfpSM8CP12Q/zdV0VXjDDNJjrs3fSu7ohoKpjHgGCp0Eg8ByeteF0RPFglETJz+bRpjm1Q3hyRM4
Bk8HLq1Y6cPGECsscRIOfOn2wrfSaZjHtGmrHVDIQbuiOivuPRyenZ++gTrZ/5Yx+SwMMS6NTrQj
NwrSt+i9BUn7sSZKkQlNeISRWzvEm3nK9PXrV8//dPH6zXenz75B6iFsgOwLiTk3Zq7nAjC5fs8k
rlWODobugfKGRkBhgLfcKVUvzLxi42pTLi1ZTc3srPJO6VB1ZM8mDVj/57Z66OPopCpmLIUpjdFP
8RHM5cNbGRdbr1HtiB8tA5e6kOC85S8jHqkpC82UP3dk3g5uqf+9Ldf/Ht6szv+eq8dh/d/r2/N/
G/i3639yYAIuYGUNMcbm4gzhjIUYpjHOg9/qtjp9kogQS+KUZlMwmUUcjfvdBefydixoCHKWtGJk
fFtnYbW1oHsDcSxmoPf7BeWmJv9bHkkGNM+mweJK319pRBh5i7o/wsI/mbeKMOLc2lzY6FkQgWEx
pnOtKCH4p3mzN7AkVv0BzfbF+eod0yJAON/X1yusw5oDTu3Dw4d4mNbp4fWX3moLQXcQhk+dTU76
6HNaj/FJ/D146pDblFg0KTa0MI0KI9WIqn14/BhlXy8k6m7FbfyKoHvKMznHuX1un7W4P2zEf4yF
9x/l7qj/PN/zFv3fzmCA8b/T81wb/7cBrP907aem5F0UxxhnweQAJHkXRhKaaXHptnRUvUncoHg3
KD5SCPnD2fnIHAYKZZEDczkVCWuP8ygO26ZIKz9GY3bFAlLDMUU2As0uNCeVRJ2ZQPPlQgFoTqHs
6rqmp+uani7mek2858FJORDPGPBPHnrwkBRJYA/PHXyOhgWLqkzUihsGzRewHqyxMgZ9CcfHp69e
wkk7ZO/bPEeDab4k5EMoBhIx/ivmokFMlUKavKQ8+jvNIjwuxBDMCIIcyEfm6K/P0V/Oce0E25ih
vzrD2xl764y9W41303beKmeSKmiyCfwAl5KVS6wzA82lLJQ3rflpYzbHldU+90b4mWI9/mO9+OKb
0/uWcVf+P/D6y/e/rs7/Ox0b/7cDsxur9R8SMqFRrGAWYfquE3q/A5SHVW5Plnl+A+Yix1L6PYNM
QCCShPGiOBATyKaampZ1QsRXAxAm6EwFMkp1RESBTTBJxxAKouYmcw76JOIsYEpROS9bFEoPXp4D
QxhTDIWoXtnBEBxM20IH8GqoVw6dSJ3KooqpFFfzBmDgV1Bm/Cgy5AqTZixSwohfakam2xbyio1f
skmiMMQ8umQiGZ51GOsV6BIELbnBpOSPsrBGGs8rJcLieeS96LcXB4OmX0qaoAEprkqU5DFFurFn
+U4TxgyNHolc4uPLbuVQ3wdTVqH9jfKJtt0lw2Gr/cr1gWXMroYSlD+OWQLrS7Sutu4bKaCTDC2u
sG6TNIZ6Qq9Q2wToWL9v7bqHQDP9YhYtgtadog+h1Wglr7QWMdOMFDyO0H3CCOcazx9jMamrvcJi
lEPZ+azjx5UGpjDK0fiwRcgZ183ZGN1tgn43xbsJVm1TmuoudFS447pkuGSoWayPKPTOFfM2zEUQ
R9pVFM5ZkRW5eissNGqYSz08iZR+Mb0pI9JugTyy1tKwirHEmGSMUgRHD89wotrnZwlU9WZTK811
Yw75otj3uDf123HNUTdtSyUlVVOYCf4oK+fa+g8O0fX4v+op9xdj7nz/i7XBxvvfvm/f/24F7pO9
3b3g4YNflmnY7h7Z3dkzv7u7O//81Uoyu5XlsNgubun/utv+/lfH7yzq//6gb7//tUX8qO9/3UeX
dhyOb3Reta1DDs560VjQ06JyJEXmJTA5dFrtlSbFf/fXrSwsLCwsLCwsLCwsLCwsLCwsLCwsLCws
LCwsLCwsLCwsLCwsLO4N/wJ4ZNBaAFAAAA==
--_004_96779DE2D69B3E4DB46CA3AEAA8C409D8B0DCCRTGMX02intranetlo_--
benintechnologies(a)yahoo.fr wrote:
> Full_Name: Ben
> Version: 2.4.34
> OS: Debian 6.0.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (41.79.217.116)
>
>
> Hi,
>
> I'm unable to set up a back-perl backend directly in cn=config mode. However, if
> I set it up in slapd.conf mode, and then convert it to cn=config mode, it works
> fine. It's not convenient, because I have to set all my perl backends up before
> converting to cn=config.
The crash is deep inside libperl.
It appears to affect other platforms as well:
https://bugzilla.redhat.com/show_bug.cgi?id=967719
Most likey you will need to build your own libperl in order to fix this, tho
at the moment I have no idea what perl configuration changes will be required.
5259e408 conn=1000 op=1 do_add
ber_scanf fmt ({m) ber:
5259e408 conn=1000 op=1 do_add: dn (olcDatabase=perl,cn=config)
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt ({m{W}}) ber:
ber_scanf fmt (}) ber:
5259e408 >>> dnPrettyNormal: <olcDatabase=perl,cn=config>
=> ldap_bv2dn(olcDatabase=perl,cn=config,0)
<= ldap_bv2dn(olcDatabase=perl,cn=config)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(olcDatabase=perl,cn=config)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(olcDatabase=perl,cn=config)=0
5259e408 <<< dnPrettyNormal: <olcDatabase=perl,cn=config>,
<olcDatabase=perl,cn=config>
5259e408 >>> dnPretty: <dc=mydomain,dc=org>
=> ldap_bv2dn(dc=mydomain,dc=org,0)
<= ldap_bv2dn(dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=mydomain,dc=org)=0
5259e408 <<< dnPretty: <dc=mydomain,dc=org>
5259e408 >>> dnNormalize: <dc=mydomain,dc=org>
=> ldap_bv2dn(dc=mydomain,dc=org,0)
<= ldap_bv2dn(dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=mydomain,dc=org)=0
5259e408 <<< dnNormalize: <dc=mydomain,dc=org>
5259e408 >>> dnPretty: <cn=Manager,dc=mydomain,dc=org>
=> ldap_bv2dn(cn=Manager,dc=mydomain,dc=org,0)
<= ldap_bv2dn(cn=Manager,dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=Manager,dc=mydomain,dc=org)=0
5259e408 <<< dnPretty: <cn=Manager,dc=mydomain,dc=org>
5259e408 >>> dnNormalize: <cn=Manager,dc=mydomain,dc=org>
=> ldap_bv2dn(cn=Manager,dc=mydomain,dc=org,0)
<= ldap_bv2dn(cn=Manager,dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=mydomain,dc=org)=0
5259e408 <<< dnNormalize: <cn=manager,dc=mydomain,dc=org>
5259e408 oc_check_required entry (olcDatabase=perl,cn=config), objectClass
"olcDbPerlConfig"
5259e408 oc_check_allowed type "objectClass"
5259e408 oc_check_allowed type "olcDatabase"
5259e408 oc_check_allowed type "olcSuffix"
5259e408 oc_check_allowed type "olcAddContentAcl"
5259e408 oc_check_allowed type "olcLastMod"
5259e408 oc_check_allowed type "olcMaxDerefDepth"
5259e408 oc_check_allowed type "olcReadOnly"
5259e408 oc_check_allowed type "olcRootDN"
5259e408 oc_check_allowed type "olcRootPW"
5259e408 oc_check_allowed type "olcSyncUseSubentry"
5259e408 oc_check_allowed type "olcMonitoring"
5259e408 oc_check_allowed type "olcPerlModulePath"
5259e408 oc_check_allowed type "olcPerlModule"
5259e408 oc_check_allowed type "olcPerlFilterSearchResults"
5259e408 oc_check_allowed type "structuralObjectClass"
5259e408 >>> dnNormalize: <olcDatabase={3}perl>
5259e408 <<< dnNormalize: <olcDatabase={3}perl>
5259e408 >>> dnPrettyNormal: <dc=mydomain,dc=org>
=> ldap_bv2dn(dc=mydomain,dc=org,0)
<= ldap_bv2dn(dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(dc=mydomain,dc=org)=0
5259e408 <<< dnPrettyNormal: <dc=mydomain,dc=org>, <dc=mydomain,dc=org>
5259e408 >>> dnPrettyNormal: <cn=Manager,dc=mydomain,dc=org>
=> ldap_bv2dn(cn=Manager,dc=mydomain,dc=org,0)
<= ldap_bv2dn(cn=Manager,dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=Manager,dc=mydomain,dc=org)=0
=> ldap_dn2bv(272)
<= ldap_dn2bv(cn=manager,dc=mydomain,dc=org)=0
5259e408 <<< dnPrettyNormal: <cn=Manager,dc=mydomain,dc=org>,
<cn=manager,dc=mydomain,dc=org>
5259e408 perl backend db init
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffebfff700 (LWP 20520)]
0x00007ffff74f5b7d in Perl_gv_fetchpvn_flags () from /usr/lib/libperl.so.5.14
(gdb) bt
#0 0x00007ffff74f5b7d in Perl_gv_fetchpvn_flags () from /usr/lib/libperl.so.5.14
#1 0x00007ffff74ea3ed in Perl_get_hv () from /usr/lib/libperl.so.5.14
#2 0x00007ffff00a1241 in boot_Fcntl () from
/usr/lib/perl/5.14/auto/Fcntl/Fcntl.so
#3 0x00007ffff755982f in Perl_pp_entersub () from /usr/lib/libperl.so.5.14
#4 0x00007ffff7550cc6 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#5 0x00007ffff74ec5ee in Perl_call_sv () from /usr/lib/libperl.so.5.14
#6 0x00007ffff74ecc2d in Perl_call_list () from /usr/lib/libperl.so.5.14
#7 0x00007ffff74d6739 in ?? () from /usr/lib/libperl.so.5.14
#8 0x00007ffff74e3e11 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.14
#9 0x00007ffff74e4518 in Perl_utilize () from /usr/lib/libperl.so.5.14
#10 0x00007ffff7512b3f in Perl_yyparse () from /usr/lib/libperl.so.5.14
#11 0x00007ffff758b38d in ?? () from /usr/lib/libperl.so.5.14
#12 0x00007ffff7595821 in Perl_pp_require () from /usr/lib/libperl.so.5.14
#13 0x00007ffff7550cc6 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#14 0x00007ffff74ec5ee in Perl_call_sv () from /usr/lib/libperl.so.5.14
#15 0x00007ffff74ecc2d in Perl_call_list () from /usr/lib/libperl.so.5.14
#16 0x00007ffff74d6739 in ?? () from /usr/lib/libperl.so.5.14
#17 0x00007ffff74e3e11 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.14
#18 0x00007ffff74e4518 in Perl_utilize () from /usr/lib/libperl.so.5.14
#19 0x00007ffff7512b3f in Perl_yyparse () from /usr/lib/libperl.so.5.14
#20 0x00007ffff758b38d in ?? () from /usr/lib/libperl.so.5.14
#21 0x00007ffff7595821 in Perl_pp_require () from /usr/lib/libperl.so.5.14
#22 0x00007ffff7550cc6 in Perl_runops_standard () from /usr/lib/libperl.so.5.14
#23 0x00007ffff74ec5ee in Perl_call_sv () from /usr/lib/libperl.so.5.14
#24 0x00007ffff74ecc2d in Perl_call_list () from /usr/lib/libperl.so.5.14
#25 0x00007ffff74d6739 in ?? () from /usr/lib/libperl.so.5.14
#26 0x00007ffff74e3e11 in Perl_newATTRSUB () from /usr/lib/libperl.so.5.14
#27 0x00007ffff74e4518 in Perl_utilize () from /usr/lib/libperl.so.5.14
#28 0x00007ffff7512b3f in Perl_yyparse () from /usr/lib/libperl.so.5.14
#29 0x00007ffff758b38d in ?? () from /usr/lib/libperl.so.5.14
#30 0x00007ffff7596824 in Perl_pp_entereval () from /usr/lib/libperl.so.5.14
#31 0x00007ffff74ebd31 in Perl_eval_sv () from /usr/lib/libperl.so.5.14
#32 0x00007ffff74ebe84 in Perl_eval_pv () from /usr/lib/libperl.so.5.14
---Type <return> to continue, or q <return> to quit---
#33 0x00000000005f345a in perl_cf (c=0x7fffebffd2f0) at
../../../../head/servers/slapd/back-perl/config.c:177
#34 0x0000000000442a7b in config_set_vals (Conf=0x90ed60, c=0x7fffebffd2f0) at
../../../head/servers/slapd/config.c:345
#35 0x0000000000442fcf in config_add_vals (Conf=0x90ed60, c=0x7fffebffd2f0) at
../../../head/servers/slapd/config.c:418
#36 0x0000000000443c9a in config_parse_add (ct=0x90ed60, c=0x7fffebffd2f0,
valx=0) at ../../../head/servers/slapd/config.c:689
#37 0x0000000000439c1b in config_add_internal (cfb=0x9105e0, e=0xa52bb8,
ca=0x7fffebffd2f0, rs=0x7fffebffe970,
renum=0x7fffebffd2e8, op=0x7fffe4002670) at
../../../head/servers/slapd/bconfig.c:5439
#38 0x000000000043a83e in config_back_add (op=0x7fffe4002670,
rs=0x7fffebffe970) at ../../../head/servers/slapd/bconfig.c:5666
#39 0x000000000045ba65 in fe_op_add (op=0x7fffe4002670, rs=0x7fffebffe970) at
../../../head/servers/slapd/add.c:334
#40 0x000000000045b2e2 in do_add (op=0x7fffe4002670, rs=0x7fffebffe970) at
../../../head/servers/slapd/add.c:194
#41 0x00000000004524a1 in connection_operation (ctx=0x7fffebffeb60,
arg_v=0x7fffe4002670)
at ../../../head/servers/slapd/connection.c:1134
#42 0x0000000000452b1b in connection_read_thread (ctx=0x7fffebffeb60,
argv=<optimized out>)
at ../../../head/servers/slapd/connection.c:1270
#43 0x000000000061435a in ldap_int_thread_pool_wrapper (xpool=0x9e4d00) at
../../../head/libraries/libldap_r/tpool.c:945
#44 0x00007ffff728ee9a in start_thread (arg=0x7fffebfff700) at
pthread_create.c:308
#45 0x00007ffff62f6cbd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
#46 0x0000000000000000 in ?? ()
>
> Here's the ldif file I'm using to set up a back-perl backend in cn=config mode
> (it's inspired from the files I get by converting slapd.conf into cn=config with
> slaptest)
>
> # Load dynamic backend modules
> dn: cn=module,cn=config
> objectClass: olcModuleList
> cn: module
> olcModulepath: /usr/local/libexec/openldap
> olcModuleload: back_perl.la
>
> # Database settings
> dn: olcDatabase=perl,cn=config
> objectClass: olcDatabaseConfig
> objectClass: olcDbPerlConfig
> olcDatabase: perl
> olcSuffix: dc=mydomain,dc=org
> olcAddContentAcl: FALSE
> olcLastMod: TRUE
> olcMaxDerefDepth: 15
> olcReadOnly: FALSE
> olcRootDN: cn=Manager,dc=mydomain,dc=org
> olcRootPW:: c2VjcmV0
> olcSyncUseSubentry: FALSE
> olcMonitoring: FALSE
> olcPerlModulePath: /usr/local/etc/openldap/perl
> olcPerlModule: SampleLDAP
> olcPerlFilterSearchResults: FALSE
>
>
> And here's what I get when I try to load the file:
> ldapadd -Y EXTERNAL -H ldapi:/// -f perl-backend.ldif
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> adding new entry "cn=module,cn=config"
> adding new entry "olcDatabase=perl,cn=config"
> ldap_result: Can't contact LDAP server (-1)
>
> After that, if I start OpenLDAP I get a segmentation fault:
> root@ldap:/tmp# /usr/local/libexec/slapd -u openldap -g openldap -h "ldap:///
> ldapi:///" -d 16383
> Â….
> 51585496 perl backend db init
> Segmentation fault
>
> Like I said, if I set back-perl up in slapd.conf mode and then convert it to
> cn=config, everything works fine.
>
> Ben
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Howard Chu
Version: 2.4.35+
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (78.155.233.73)
Submitted by: hyc
In 2.4.35 (commit b1da555c4c7275d7f756d693c42814388a9aa839) code was added to
unconditionally turn off readahead, because it is harmful to random read
performance when a DB is larger than RAM and/or system RAM is already full.
Unfortunately turning it off harms sequential read performance. It should be
configurable, since different behaviors are needed in different use cases.
h.b.furuseth(a)usit.uio.no wrote:
> I wrote:
>> OTOH if you add a bunch of slightly smaller nodes, mdb will put
>> most of them in separate pages anyway without MDB_APPEND.
>
> ...because mdb_page_split() has been wasteful since 48ef27b6f5c804eca6a9
> "ITS#7385 fix mdb_page_split (again)". When a txn put()s ascending
> keys with nodes of the same size, the new item goes in the fullest page.
>
> E.g. put data size 1010 with 'int' keys 1,2,3... to an MDB_INTEGERKEY
> DB. As the txn progresses, (page: #key #key...) get distributed thus:
>
> Page 2: #1.
> Page 2: #1 #2.
> Page 2: #1 #2 #3.
> Page 2: #1. Page 3: #2 #3 #4.
> Page 2: #1. Page 3: #2. Page 5: #3 #4 #5.
> Page 2: #1. Page 3: #2. Page 5: #3. Page 6: #4 #5 #6.
>
> 2/3 wasted space. Descending put() work better:
>
> Page 2: #6.
> Page 2: #5 #6.
> Page 2: #4 #5 #6.
> Page 2: #3 #4. Page 3: #5 #6.
> Page 2: #2 #3 #4. Page 3: #5 #6.
> Page 2: #2 #1. Page 3: #5 #6. Page 5: #3 #4.
>
> Ascending put() with datasize 1348, so only 2 nodes fit in a page:
>
> Page 2: #1.
> Page 2: #1 #2.
> Page 2: #1. Page 3: #2 #3.
> Page 2: #1. Page 3: #2. Page 5: #3 #4.
>
> Half of the space is wasted. Descending order does not help.
>
> page_split() cannot know which split is best in this case. But it'll
> help to guess that the next put() key sometimes will be near this one,
> and ensure that the node with the new key will be the smallest. That
> will also avoid touching the old page when the nodes are that large,
> since the "split" will keep all old nodes in the old page.
Fixed now in mdb.master. On a large DB, the previous code used 3276587 pages
in slapadd -q, and the new code uses 3272633 pages. It's only a 0.13% savings
in this case, it seems the frequency of these insert patterns is quite rare.
The runtime is also 1.1% faster going from
real 41m35.8s user 50m57.6s sys 5m11.4s
to
real 41m1.7s user 50m25.8s sys 4m55.3s
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc(a)symas.com wrote:
> michael.vishchers(a)7p-group.com wrote:
>> Full_Name: Michael Vishchers
>> Version: 2.4.36
>> OS: RHEL 6.3
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (109.41.86.33)
>>
>>
>> The bug mentioned in ITS #7716 unfortunately still persists in 2.4.36.
>>
>> We now found a way to reproduce it:
If you want anyone to spend time on this:
Send the stack trace from the crash. Also send your slapd config, sample data,
and the actual query used in your client.
>>
>> - make sure that threads can run freely (i.e., provide enough cpus)
>
>> - start slapd with the rwm overlay
>> - run a client loop that
>> -- binds as a valid user
>> -- sends a valid search request that is *immediately* (i.e., don't wait for any
>> answers) followed by an unbind request
>>
>> after several iterations (with 2.4.23 it was between 2 and 7, with 2.4.36 it was
>> about 30) slapd crashes in malloc.c
>>
>>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
michael.vishchers(a)7p-group.com wrote:
> Full_Name: Michael Vishchers
> Version: 2.4.36
> OS: RHEL 6.3
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (109.41.86.33)
>
>
> The bug mentioned in ITS #7716 unfortunately still persists in 2.4.36.
>
> We now found a way to reproduce it:
>
> - make sure that threads can run freely (i.e., provide enough cpus)
If your client loop is running as a single thread then the number of CPUs and
running threads should be irrelevant. If the number of threads and CPUs matter
then you're misusing the API. Closing this ITS.
> - start slapd with the rwm overlay
> - run a client loop that
> -- binds as a valid user
> -- sends a valid search request that is *immediately* (i.e., don't wait for any
> answers) followed by an unbind request
>
> after several iterations (with 2.4.23 it was between 2 and 7, with 2.4.36 it was
> about 30) slapd crashes in malloc.c
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/