(ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael＠stroeder.com
----==62f1203288d98ad3817191f9b713342b
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit
See attached a canned MMR config.
The behaviour regarding contextCSN is really strange. You have to play around
with some more modify requests changing the group membership of e.g.
uid=michael,ou=users,dc=example,dc=com
If contextCSN values are out-of-sync restarting one slapd brings them up to
same values again, but the older(!) ones.
Ciao, Michael.
----==62f1203288d98ad3817191f9b713342b
Content-Type: application/octet-stream; name="openldap-testbed-its7710.tar.bz2"
Content-Disposition: attachment; filename="openldap-testbed-its7710.tar.bz2"
Content-Transfer-Encoding: base64
QlpoOTFBWSZTWS/IcOYADFR/tf7wKIR9/////+///v////6AQAwAGABAAAAIYCFvtXi4dW2a669a
8s1s1Rhe5yWddW7l1yqUkKAAbndwwp7MoLnuA0NGQQiklFraDW2yGgstttdd3rg600iUBSNY9UNd
wkkITRpponop4mCamyNJpk0AaaExppqbU9RtT01GRkehqaaAaCRIAQhEYmTKp+TUyJ7U2qeaT1R6
nqPU00NAAAGgyAAAJSNEUPSHqPUDQAAAGgA0AAAAAAADQCTUiTKCeU8gT1JtE9IMgGjJoNAaDEBo
A9IyAABocAAA0DQ0NDTIANAABoBoaAABkAABUkIICMQI000Enk0Jpkn6kw1Mpo08oeoNAepoAAaN
A3uEH6CD7VzHMcwP95Q4z5/a/W+muViqEBA9LoELQ+yG5pE6QKpVVFoqkKJK5SAA91fdED90pwcj
ETpHul0pWt3UnWxSVZXEfwDXYhmQxOBCoGLpYKVKk0rJDc2ZnDIqQ1GnDh6nMcQQEjCaq/CsnDpe
UrShWFkREW4QMQZAEWQA55AZJCMqJJIIEDGqhBCCESHHIJzoHAnHqALsFkiISUw87bDPpM9dPSXQ
y7v3nuQvnO5desdcbdm/ClPly8QLLcIX4EMjg8h/F8IDO24uMg2w/jVN4wlUfHBS1j0ECUvmUqVP
QVDEXTUGGPgT0QsesuFc5zQaRpCLjDMEwNZ4BT/Jp/g+x0Wo7kxeHqYJoZrB4yBnDnDUJaS+Th9Q
4xhAypWBkMyAwptA9lq3M19qIP0Ra9xtGiPblilklhUlrmqMYOo54VKqSqqU0z+z9h9bvKfIeLcw
e9r2K9bDkfDp0GoZNkWFkhi3S6x0Vc92K0oWN+jdf8ycsSz7RsESk2X1sLMLeqz6zZY43M17VXVq
1pdiXfUtZ3qUHm7JHmbTLDoaiHU7ivVlqqFYPqPmOZMUCYV+nad+OR1kJmm9MoXTaHGxnMesLYbL
E7YZoYg2YDi62GjP4tqcyjk3+d0esUKmTJ5YPQdiw8tpZHpq/xkseLVTCnBuPJsdfZv4PPJ7B9wP
rMHI5Z1nTG0zaq62mMr3+j3VXxFToMe5w5HpZIu9azi6ts7H54hREOR8bNKEkBIHYiSSCh6BJw2D
S90wlAnbNgKAVDUon5lI+NnqeazJPpUu53rh+XV76v9ntq/L8XRjfuxJWuuilkxxR6zo6g7ssFPf
IN10C4u6mGEJ1IpUxE6Sv1H+0qeS8hhK7XTcw7/sz9OefSkg+SwRqYZGoyJrGOHOo5jrm8QeKQDH
wo2ex0aS5cpUt9PjkonyYPci5mmx8oeVfD6vKQ4foVmSqk8x3cMsUA3KyCgPYZBxQPJzsZjrHgNT
Qasr/CMJ0HK76MW9Tm8V5K+D4LnlZZvV62RsLx/v3Z+HzZCkeRk8iDgplhScJ1gUz5bHh/ScFKr7
zDQxa0X5ky9fcbnL1yO8z4C6n7zmR28l3mxIZ7PSrEWZo2+Nn238PuM2TfRuN/he+/wp70fnqTHF
weVXK2OqIlL816UcywkMAWxzB28o2mE5rG4i3bnE0MhdkMA5Iay+SuUp4Ul4ifpWykvCvAsVUt4A
KNI/F16kei0SZc5Qd5Q6/6yQHu85v5g+qm+qZvm+O/p3dA1y0WhjKTF+eaILxbdQWU4fqKvAwERa
JsS8KqBjxXfZucXYOuL4rKd9nm9Tg47a7uW/t5JlOztW2KldoIDIdXBf+Sxt1dR1s8Yi8Q5czzTV
z0nefZem/iBYMHQ6HHUUiZMkaML1JLrI2fLY9vQXWZ0ekcPouOg/1lbMWdJYyXTfgUyIMK2QyQrk
UQxE9Jhi28oQyfHdg47lDXkfIUqdhrGlhniPUu8qVx+USNyTs3A1hi8ZApK2nVqsZ5jExSVe812B
OwaxUMRVtNYvIkbqDz9nrJlD12I4VhsO5IGxR4S/QimGZWxuWKLb8njUn3cFV7QoS8usdnk5h1HM
0fKzkYgNJiL9BSKXJLsK3+0cygeO5iJQ00+ZevPw9F6LU2eza8TqZvmh/pfk+7XXi+pc6HiUWet6
L1VP4LLKbNvm62G+jgj0UooUoUk/sE/+KRVIlUiRSpFUI6xE/C0ksRKGCRzzS0u97Xv2vX4V5393
oszeWvbkx5tmjb2eSCVIjaQ4H92x4H5hol43mrlI2t+TVu36sGezuBoADuG9qzbLuZVuJus6BbLd
yceDbnLIxENweE4ygKCA4AXT9k1V1ie4WTzyiG4OuebNNnW1csjzsDcMcheIKmKD9508/BJPY2T5
DFZjxGkJYTKnHQJ3GW0LDvGn0d6mTvXWehTySR9ck/Goefn8W50YaKKU+tZub2i+x58bQq1UrNqb
W4zND+lY6jR1u+hLqpLm5eWI5PXBcsZHhxhMCM4rJ6i8Ub1I/xBVPNeOQA85weMEekxAgtBg2RwT
0oBbSzCSvyfBm3SfhliBXv5P/J1ON21NkE6nxeDNtVOXW5lq2eR/fMk1nRN/p3PGvSk6kgVKQij1
AIVTaEKCrhCs1jCQGpASQvG9M89owOrReLSJ0gBEl1iClRk0hFG3DwxIiVgLZAQtVhzSLI2a+kq+
cOUetrAwwVdw3zHefbgzUySYOGo5zk7caSlq0c5E6pKzTqML5hMEUcVPCL1gkTXyscVzGS+3RKZe
6+uWLWXVgXANgK0gN5DMI6r42TJqVGcxUIXEJjXLxUuIUHiLoG5sBuUskbIYNDH2GRyN4IIiEUXi
hQbt/Dic8kN8Pdd099yGUGKqymFXIkPE0aa4PVMDWZiISGAdjrn7BbObBQis4WBk2Zla80XkNEGR
ZEWMFIKqqjzyG9LopmRI83WWbNLESKaEP534V0h5G3+OpxDyrZHlTn57VXbO0e/k4zpepraSD3pT
CBkhyQefKdCFvDorirqw9DVDT0vzWmvqas0wIGixYlihRBUJECUDgcGeIKHjawys7tDlbftNhOhM
30VFD30YGnTJJFgdnAUyZUhMpLm5SGmjN8NcbrbkpvYbGnrPD53xy3nmPZjRowe3bNf4pRn416zZ
mJYsuC/LqSCEkHFXEUSOVQm6m/WOTnJfVsNdOvGTgwRAkh6OxR1GCg5kMJfiKYyYvMEWP7hmJWrg
kkFBCzyWOqNtjOfR+MLkQkWJGxZmKoBX3EMnHhIYrOQ1edltrDqrDFMLdmnoxwU1aEHDUhmxAumC
DTodOvHWYCjbFxce8a80+VKWpj0c129vQd6y7jbu+kL3V7Ajl5pHUNgYKo4dJOuanVVtuqyymxXI
qdjdIWG+hno8fV3RGXcztqiaouiYYuutfLKrv25DfLrIJzGxBV5oFFZUo8lihTZwO0T4FItqETw6
JSaUMIt+0lKjtMqa7W5jyx2wTtqhqXYVQIz9Juv5k0kNJbT8qq/JLRAaipJMkQkckIggqIGOfLnH
O4FpXZYmYJjIcjpTJOlultcmGuJE4KbtS21iyFzBq0Ql2VAm11XW5nG94MpIVAY0aktVxTLcdRZA
jO2WWNkE4HSmwTMMqDKgMm9piUKgyRsCDZIJKuM0K4apahMkymWkEj0mLVxLOJk5+dA9bN1VKBfj
aeBTrfEylY4X3lUmkHCEEHUZUg50VDQjRuWgzsCIUuMEgMsApE3G5orRWktTCvKhIkGzCnAj7aaE
csHoDFeNiCnFM9IdNuR0JdCwCLIRzGlnoKCxyFQyVIbOKrd7FCk5YiqqTd0gvaVuDWcbsqrJBc0k
+CgyzIrBYCTdsVnOLmRZleouMWuINgW+GSA1SpMvJAKhGZOlCD9tVglWICsViSkCBhfjMwskyp4o
BdlrUL7EHO+rJU5pVS1WnOJ830NByKLcWA5oBP1M344CXDLWJ1hkyALvROFqlxYnNtAoaSKWr24v
yPVjayXOutHMpPNtkm9yshCkkxEwaE7Vyr9BQjkFVSeD2lYI8QuPm9PSDtt3OAHDh6YYYHdvdoPj
5xe0wlhqJdLZqt0Qmg0hydn1OtIpdd2ruK0URUeacJ7HESHVvc1HJOmfYZFzaBE1FE6NBS7sf3V3
8zOQmUd1SHJJGS0skhkkK5KZ98oYCxCLUIFWZNKRQhchfwglTk0jZC6HMD5LnEPPcoH1982w6aS9
oA8Qj4CnSqCPkSxrtnXXgFD3JI9STrPKfcPHHIJxdNo8sF0yIKBN3uuONRCZZxlXyArYJXMHQc4P
DxG6fqHVIsm4JFJXDTKUlWGlS/ZFJ3DMsaDIMhMy3+kTUVWioqnrXvd1xPaiKjeHgdG85f0HHiUK
r59IyUSVvjg4/ofefVlzVwfUdpw9Gk25Hr9DS4Y2GHF8ENjdTf3I4tZVP4nd4KWXOnsPzI3HpD/Z
meE3P/DhJNhycq/fyjYc2g0DzADDMytBnsjCgaL4YwC+IiSXCeYcB9719G09r1vxPofRVU2Ijktc
7p09p+mVVrXtVH2t7j+Mm6O97bW977+JK4yS0Tkd5HxN7/WiILhX9MyxuDGwbVjle6Fry0IIgJgL
GVc+sECisbEESYKQ0B1LhGsgtU1Sus5QiwSKZ2J+Wwd8HxD1ZN2MiNtJZFiD5g4M6M5xCCwY6w29
OY69p0kqWE96HX1z5mxf7soqOSO3ZVT7JymrjR3KbCT5HjH0ipueavidRqZ5qRSy0sUqKlHHgYuI
YtnQWnzsdUoLNSBrBa6RQsqSGG7RS8pWhqxiSenexUpOSdfHnR1aOp/TJPj8opUjwdUk9W/7j4uh
Oqdbvr4B7p7DRg0b1RHcsjks+1yGUldUkrrkjBq5OD+JLo/4v2v3p8D70/YfgQ+ZH208tvwvLFqm
KRdap/QqIwJ6hr6/+ePcq6r4u+ja+ZKfe9yxZZKWMbRXBuwVzfFujHQPOwbAjnBMDAyrGynCB5Lo
pwl8Co1NdpwD0l5xpyKmNcFhke0nEicuyFSD8ZUKKUEFEfNqZ67H4Q4F0S1uBGxUoe8NtEUEEgrB
EFhGhDdkkM23BxtSqoNl51c2srr/QO9kiomumRax4wSdiDyXdxDXGk5vJnJ+14nrZ7BlZt6/RiTp
afC/LqDEU2anVJDP3t0qL/Gjpuzem0hfsRPJD9LLvrE5c+WW7QtOLeh+5o+CnNTjitrylzDK1I07
pJKWp+xkLeNePuKvoaDvQ+3uL9DqSiqVSdp5qT6FkHedSCx1DCUc1Urx6f5x7E9rKJxgmBbjJDcz
yfbKBuNL7/3If1pVaGhA1kS5rqKkAWi11BsT6xhKRTmYN1To6VyFYxUWkki35XHFxSjWKl5BhKKF
rSMPIPTSGqGRp/L49rfl03PoZmUiflqqkitJsvvK2HC/WKubUYWuqku4Q0k4aSLTcnyWn7lCFFUS
gqINAiihd4iQ0IQYAekUsX7qjAofaqOth2SH8OttH9TsarpiNXNdeQWVDsUmSGLE7FZJopjEuxf8
9Vi8d6vpaFozsllpzMsFYyVdMlgzINQUMUJExoY8DrggZcEQgFSCTA9QVldMRYiG7LsGQA7nySJJ
Uy2aQEnDmGxLPQr18T3KfJ8pp6pJGgpKpPUUopG0plvcnvh0UqeqntYm1PCp11rO3td6yOC6GvbU
0tkvbCJLu41Q356FBkwvoUy8m9j1uwzN6pyN22UoeBgfw0SqObiYMzrv1Ib5kdukOLg4LcCnqVPO
seXhKcEvliakCbSDElIaUMICDxOTOYU0SqbHbQ9xMzOUhla7kYjgkZICGMyjibghpnlery9Q9QaN
XkUJBwTktnZYZY0cuIDjMFqjeWmSgSQw0OoUMzfFSs+nIrKaFnGsi6imUhLmWF2Gla1Ly7Gqt7Eb
oq+UH/dCj9NKjVZrms3VyGUn9SEulfCOzhl1cVr1Gtra0uplHvZMnbBNJox9aXyegkO3ajYmEH2L
kbnzptp0KYRoUgk2YOZ6eX0Dg8/PphOEblbXM4E4OkRP312kxHjNZy863N3hbNn29GD4lTIdHU7N
BDiOlJhbS8tRZvW+wk19Y0t/NSh0DIt0xMbdhNh7CEUEF7w3sQQvIHxQ6qbcEFWQXFcmTbdLSkwO
TVchkqIxJqoWZsM0qM02P8Dzdz+Nu9zVum4lbv31BTOOCVnIUoyQ/U/OcQG22+lSqO6D2Skvz6yx
O1oIPkLz7waqu1FA7lJKVIdbIg7JUZeSi2d6W0fEbN5lozkk2ZPF+P8V19D1tzlSTHySRsKbXlHV
02qpSnQ+tXBRJd6uD+NPNqw9VnsK66GqL9G5iuguFCR8w0uyJEvpaqNBPG4Kq+Magjky4J0rlQmT
JgQqFi0mWtJkYEqFlbb8IhswVoj4zR9BknUoVmXD6FBtIn6AhI9MTDjKKp+VmbR2HtiUpsPSpaU1
qWqQuIJQHZPSL2KqVUQLwSQnwDOk4By2a1Sk6u+J0PpfF7G9no20o8ZctU68Gj6Vp20zNlUXiHxL
UqtotJ9fyxL4O85fyYm977bbPpqLKLqXKWejinI3OLY0ar930NudWHHerI/kU58BbMossmjicqc+
OSfB6clzm2RE7Ep03HwtJpuNLK983OY+6Rp8mFwVYPwcGzdsMK/l+qDt6t9HSGMaFwQHnzMN+ejn
S8dqOHwTsWJbotp4tjaG5Ukfh6IdJoNcQ8s0G75rFkzmmIIKpliZt3XshjgCHBwue9E50DKyihAZ
AmztAkpjR4GUmQG17YJiNJLs+8zbihxSx1xE3uxkhuDwMJQpOgZ5mtIxM40k1lcPMKffqls0qq2q
lVV5GzzTkYb5nLeCYaCxKmmoisuVOmlsupZouzbjES0qG1vqVX4jHzKZoNdkj9xSkPcs/J0OHpRs
Kar+tVrux4UqRKkknfSqlfkT7WHhPqNe5vnqPU9fUszKYUpYtelzJJFKjqkYJaKWUV4NFl1wFiyX
PYoLrJlg46XqLj7CEsJoORcS3Pgpz6ngjkodr7nsWeyTpOHWp1u5kwdsjJ8Msu07Ei1aLLYFrJFP
a0XkkXdkROuPtV7cpj0xsUkzVL0zGELqpKFHpLn3NqGtSb1BpV4l5CUpKWybHNLFxnsSqqvSvGqn
FRiZ+DLIXavDBfWbi+VomHBW4kw3GewGYRxkYkho4CQ+dGj2yBnhLECyqtUZBqNHQ2A8Bhssdqpq
DgosCXrOS0lhGqIljeGxZUKmJmL3xCIgMVGFJJDQ0xJFEK6qiGdkKA6xxxkPdT9Rh+zUub5D7bJK
cL2Ww20wvLrjzC5gGEWgnUBm2MGRE2mtRmJQbbKCYgqSSLMSMIgcaYYXZE3Rdn4VIFgCGUDbCF44
U2PdK5bcTZTmpaSk1FnE1goUREopgsUVEYIpdmeF4F5ktilIqo9yyzCmdOdJtdpbNxkUfY2cYAM6
8shAwAbgMLeGFjK8YxlEuoDJLUUznrbpm1OX3Pd+PCrS0hoSGSjOJNST6UvfM/Sy/op59zZJFk0g
DXvJ4QHFGNDe4e0w5RaMoSipQiCUUVFGQWcRxBkYI6EEyQYSBoBTtBR4gxCUMMsjEK0UukSdO0f0
TtPtd/v2MslqVS00Dnt1m5gOAWqQN4znSLku6k8pYqT9fnf8yMdPVMDSZMptUuljTSjveKz8jb/K
sj5PplRwqJVSq0ab5tI3SSYlDNoUpZ9J+JU37X62TE3vtf2YqSQ/LKSKKHMpZHxcPUOyLPv40tKa
IPpSG5r8n81xDSlQ9VZ6tXsdrhhHzbzikT0omhjIX5otTkQch/PLqRueqntyo7pR4iGsX8wVEonR
TMGXeWtwqq2ySuctEcCGiWCCiKCIixhVBFgEmMlzhosTbZOE0tvTJzHNBZh351dZF15bdeYUWXN6
TjTg8V3Y1ZaJbidR1tDOlc82ad2M41VqpheRZEz4ccxjYuYG1TdICLEHz5YoaMpbHuR2xZgmSkio
qM2ZIWKb51OsaO5vaPVJJglvzzsWkRtddiKFXiRMZM5td4qpchSVGEEQLJoQUXlrwnuTMVbmThYp
4GTrrJBM+I9ebroPy8r7I8iFswsaUHIxMRzORDq9zNd3XAmfAgCk8wZOcI6Smm6lWUsN+dKUY3mh
hqya5obb6REwZIb2brTZhlNVp+x3sY2e47qO+ke1ZayrwRJd7LHn0+iTWYBQ1Q9ZpE+bR2MqfAsP
4zC5t3S15FVJH6bfRzWzVTsczm2MnKKbSd7h0YTryLcjPBwOUbmc6bJeL3vLxd+thSnWhfo4+DGH
UriFTI4jrcEUqSgpCnNVi6yFsFIpSutyYKsusQ6jVwGcEzZ2go0LS2XghysQ1K6TETdM9I0cWj/M
anWdhiWRxLFylKNJNcm3aXS1p7Jzq9UUuWTrUddsLqV+HqrIVMKPOM8xPWVUKaem3RqpMwWsEgoT
DyJjIUqRqka5rKYUXUrEicdt2MiH9woyvLIvefrxGIJkNENYXbzcm5QgemizRcXUarxQKC95gNfd
JhkZc0XWTwQCfmb70KEcyqSUGg4kmXHgkEDGlQJA0aIOwoELYwJgfaLHgpiylEDhw2pVLRGkREWr
GGY2oBcyZJvjMkMAY3IeyuldHaVSIJmlkKgBzGVFwzQvYdxpO43PaZIMXei1USFl21eXk2qOpuY3
XF4JyxHE+DJB3tbaI2SSbaqbLOpJPhacFq/n4J2pJRU6yx6ZHU4O1dg0WuJwTq9qHlB5dHnxL0q1
QpO8T0iCgvsAxuKelSSjpnM5SdNh1z+bPe9r9+WcQ8HfLJM080admRETASmQdsMapgTv+EDPWZB4
WLRpjir9AhvXwg4RK9/osyUp7KLPQw+XF8GqlZaKnzWFLWYxY+BavmXWLsntXw1lUKniiyZqNDkd
hdClzDaVTrksqjWhcvEXp+ZiSRa6xejm6/PxX0ezy07SdEZQkyWJgQSQQMungKBWqhlmigVRBk3T
2nNCvYtTYf22oKo1ZbGy0ncexzDFIdmjfO+d07XcrrjxhRpBNZ6Zj3nZPtrvLxnbOShIX/i7kinC
hIF+Q4cw
----==62f1203288d98ad3817191f9b713342b--
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by hyc＠symas.com
Howard Chu wrote:
> Željko Nejašmić wrote:
>> On Fri, Oct 4, 2013 at 10:26 AM, <hyc(a)symas.com> wrote:
>>>
>>> Thanks. So far the output shows nothing out of the ordinary. Can you also
>>> provide the output for:
>>> ls -l /opt/openldap/var/openldap-data
>>
>> root@spr101:~ $ ls -ahl /opt/openldap/var/openldap-data
>> total 100K
>> drwxr-xr-x. 2 openldap openldap 4.0K Oct 4 07:54 .
>> drwxr-xr-x. 4 openldap openldap 4.0K May 28 08:49 ..
>> -rw-------. 1 openldap openldap 88K Oct 4 07:44 data.mdb
>> -rw-------. 1 openldap openldap 8.0K Oct 4 07:54 lock.mdb
>
> Something is flaky with your installation. As I wrote in my previous email,
> LMDB always sets the file size to match your mapsize, to avoid this SIGBUS
> issue. Your mapsize is 38654705664 (36GB) but the data.mdb filesize is only
> 88K, it should be 36GB. You must have some other process running that is
> truncating the file; there is nothing in OpenLDAP's code that would cause this
> behavior.
I take this back, this is a bug introduced in liblmdb 0.9.8; it is only
setting the filesize on a newly created DB. If you had an existing DB and
added writemap to your configuration after the fact, the DB size wasn't
getting set. The fix is simple, and is now in git branch mdb.master.
>
>> root@spr101:~ $ ps -efa | grep slapd
>> openldap 44012 1 0 07:54 ? 00:00:01
>> /opt/openldap/libexec/slapd -h ldap:/// ldapi:/// -F
>> /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap
>>
>> root@spr101:~ $ mount | grep sdb1
>> /dev/sdb1 on /opt type ext4 (rw,noatime,nobarrier,data=ordered)
>> Do note that we did load testing on ext2 and ext4, with both being
>> tweaked and not, and as far as I recall, every combination of
>> parameters causes the problem; I will try to reproduce it on
>> ext{2,3,4} with default mounting parameters. Almost forgot, we did
>> tests using tmpfs also, with the same outcome. The whole /opt was used
>> as a mount point for the tmpfs.
>>
>> root@spr101:~ $ fdisk -lu /dev/sdb1
>> Disk /dev/sdb1: 400.0 GB, 400027127808 bytes
>> 224 heads, 56 sectors/track, 62284 cylinders, total 781302984 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disk identifier: 0x00000000
>>
>> gparted doesn't seem to be complaining about SSD block alignment:
>> root@spr101:~ $ parted /dev/sdb1 align-check opt 1
>>
>> Another thing I'll be trying is making a partition with different
>> alignment parameters to see if any change occurs; tried using a
>> different scheme, but that hasn't produced a a change in behavior.
>>
>>>
>>> Note from the mmap(2) manpage:
>>>
>>> Use of a mapped region can result in these signals:
>>>
>>> SIGSEGV
>>> Attempted write into a region mapped as read-only.
>>>
>>> SIGBUS Attempted access to a portion of the buffer that does not
>>> correspond to the file (for example, beyond
>>> the end of the file, including the case where another process
>>> has truncated the file).
>>>
>>> LMDB always sets the size of the file when using the WRITEMAP option, so the
>>> SIGBUS condition should never happen. The pointers in your gdb output are all
>>> within the bounds of the map and mapsize you configured.
>>>
>>> What filesystem type is the data directory stored on? This is looking more
>>> like a kernel or filesystem bug than anything else.
>>>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by hyc＠symas.com
Željko Nejašmić wrote:
> On Fri, Oct 4, 2013 at 10:26 AM, <hyc(a)symas.com> wrote:
>>
>> Thanks. So far the output shows nothing out of the ordinary. Can you also
>> provide the output for:
>> ls -l /opt/openldap/var/openldap-data
>
> root@spr101:~ $ ls -ahl /opt/openldap/var/openldap-data
> total 100K
> drwxr-xr-x. 2 openldap openldap 4.0K Oct 4 07:54 .
> drwxr-xr-x. 4 openldap openldap 4.0K May 28 08:49 ..
> -rw-------. 1 openldap openldap 88K Oct 4 07:44 data.mdb
> -rw-------. 1 openldap openldap 8.0K Oct 4 07:54 lock.mdb
Something is flaky with your installation. As I wrote in my previous email,
LMDB always sets the file size to match your mapsize, to avoid this SIGBUS
issue. Your mapsize is 38654705664 (36GB) but the data.mdb filesize is only
88K, it should be 36GB. You must have some other process running that is
truncating the file; there is nothing in OpenLDAP's code that would cause this
behavior.
> root@spr101:~ $ ps -efa | grep slapd
> openldap 44012 1 0 07:54 ? 00:00:01
> /opt/openldap/libexec/slapd -h ldap:/// ldapi:/// -F
> /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap
>
> root@spr101:~ $ mount | grep sdb1
> /dev/sdb1 on /opt type ext4 (rw,noatime,nobarrier,data=ordered)
> Do note that we did load testing on ext2 and ext4, with both being
> tweaked and not, and as far as I recall, every combination of
> parameters causes the problem; I will try to reproduce it on
> ext{2,3,4} with default mounting parameters. Almost forgot, we did
> tests using tmpfs also, with the same outcome. The whole /opt was used
> as a mount point for the tmpfs.
>
> root@spr101:~ $ fdisk -lu /dev/sdb1
> Disk /dev/sdb1: 400.0 GB, 400027127808 bytes
> 224 heads, 56 sectors/track, 62284 cylinders, total 781302984 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
>
> gparted doesn't seem to be complaining about SSD block alignment:
> root@spr101:~ $ parted /dev/sdb1 align-check opt 1
>
> Another thing I'll be trying is making a partition with different
> alignment parameters to see if any change occurs; tried using a
> different scheme, but that hasn't produced a a change in behavior.
>
>>
>> Note from the mmap(2) manpage:
>>
>> Use of a mapped region can result in these signals:
>>
>> SIGSEGV
>> Attempted write into a region mapped as read-only.
>>
>> SIGBUS Attempted access to a portion of the buffer that does not
>> correspond to the file (for example, beyond
>> the end of the file, including the case where another process
>> has truncated the file).
>>
>> LMDB always sets the size of the file when using the WRITEMAP option, so the
>> SIGBUS condition should never happen. The pointers in your gdb output are all
>> within the bounds of the map and mapsize you configured.
>>
>> What filesystem type is the data directory stored on? This is looking more
>> like a kernel or filesystem bug than anything else.
>>
>> --
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by nejasmicz＠gmail.com
On Fri, Oct 4, 2013 at 10:26 AM, <hyc(a)symas.com> wrote:
>
> Thanks. So far the output shows nothing out of the ordinary. Can you also
> provide the output for:
> ls -l /opt/openldap/var/openldap-data
root@spr101:~ $ ls -ahl /opt/openldap/var/openldap-data
total 100K
drwxr-xr-x. 2 openldap openldap 4.0K Oct 4 07:54 .
drwxr-xr-x. 4 openldap openldap 4.0K May 28 08:49 ..
-rw-------. 1 openldap openldap 88K Oct 4 07:44 data.mdb
-rw-------. 1 openldap openldap 8.0K Oct 4 07:54 lock.mdb
root@spr101:~ $ ps -efa | grep slapd
openldap 44012 1 0 07:54 ? 00:00:01
/opt/openldap/libexec/slapd -h ldap:/// ldapi:/// -F
/opt/openldap/etc/openldap/slapd.d -g openldap -u openldap
root@spr101:~ $ mount | grep sdb1
/dev/sdb1 on /opt type ext4 (rw,noatime,nobarrier,data=ordered)
Do note that we did load testing on ext2 and ext4, with both being
tweaked and not, and as far as I recall, every combination of
parameters causes the problem; I will try to reproduce it on
ext{2,3,4} with default mounting parameters. Almost forgot, we did
tests using tmpfs also, with the same outcome. The whole /opt was used
as a mount point for the tmpfs.
root@spr101:~ $ fdisk -lu /dev/sdb1
Disk /dev/sdb1: 400.0 GB, 400027127808 bytes
224 heads, 56 sectors/track, 62284 cylinders, total 781302984 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000
gparted doesn't seem to be complaining about SSD block alignment:
root@spr101:~ $ parted /dev/sdb1 align-check opt 1
Another thing I'll be trying is making a partition with different
alignment parameters to see if any change occurs; tried using a
different scheme, but that hasn't produced a a change in behavior.
>
> Note from the mmap(2) manpage:
>
> Use of a mapped region can result in these signals:
>
> SIGSEGV
> Attempted write into a region mapped as read-only.
>
> SIGBUS Attempted access to a portion of the buffer that does not
> correspond to the file (for example, beyond
> the end of the file, including the case where another process
> has truncated the file).
>
> LMDB always sets the size of the file when using the WRITEMAP option, so the
> SIGBUS condition should never happen. The pointers in your gdb output are all
> within the bounds of the map and mapsize you configured.
>
> What filesystem type is the data directory stored on? This is looking more
> like a kernel or filesystem bug than anything else.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by hyc＠symas.com
Thanks. So far the output shows nothing out of the ordinary. Can you also
provide the output for:
ls -l /opt/openldap/var/openldap-data
Note from the mmap(2) manpage:
Use of a mapped region can result in these signals:
SIGSEGV
Attempted write into a region mapped as read-only.
SIGBUS Attempted access to a portion of the buffer that does not
correspond to the file (for example, beyond
the end of the file, including the case where another process
has truncated the file).
LMDB always sets the size of the file when using the WRITEMAP option, so the
SIGBUS condition should never happen. The pointers in your gdb output are all
within the bounds of the map and mapsize you configured.
What filesystem type is the data directory stored on? This is looking more
like a kernel or filesystem bug than anything else.
Željko Nejašmić wrote:
> On Thu, Oct 3, 2013 at 2:57 PM, <hyc(a)symas.com> wrote:
>>
>> Željko Nejašmić wrote:
>>> On Wed, Oct 2, 2013 at 6:43 PM, <hyc(a)symas.com <mailto:hyc@symas.com>> wrote:
>>> I ran the whole test suite for mdb, and as far as I can see, every test
>>> returned OK.
>>>
>>> Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 firing
>>> to openldap on RH 6.3:
>>> ldapadd -h 172.17.101.150 -p 389 -D "cn=admin,dc=test" -w test -f test.ldif --
>>> ldif file is the same as the previous ldclt command. Doubt it matters, but the
>>> ldif file is 1M adds.
>>
>> Can you provide your slapd config and this LDIF?
>
>
> LDIF file is just 1M adds of the following format:
> dn: uid=XXXXXXX,ds=USERS,o=STANDARD,dc=spr
> objectClass: sprUser
>
> I've uploaded the config here: http://hastebin.com/nicecafaci.ldif
>
>>> On the RH box:
>>> - compiled openldap with -g -O0 and previously used flags
>>> gdb `find /root/openldap/ -type d -printf '-d %p '` --args
>>> /opt/openldap/libexec/slapd -h "ldap:/// ldapi:///" -F
>>> /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap -d 0
>>>
>>> gdb output:
>>> bt -- http://hastebin.com/hefikekaxi.sh
>>> bt 10 full -- http://hastebin.com/vudocosuka.sh
>>
>> Can you also provide the gdb output for
>> print *env
>
> (gdb) print *env
> $1 = {me_fd = 15, me_lfd = 14, me_mfd = 15, me_flags = 940113920,
> me_psize = 4096,
> me_maxreaders = 126, me_numreaders = 2, me_numdbs = 13, me_maxdbs =
> 130, me_pid = 43974,
> me_path = 0x8c19a0 "/opt/openldap/var/openldap-data", me_map =
> 0x7ff6f721f000 "",
> me_txns = 0x7ffff7ffb000, me_metas = {0x7ff6f721f010,
> 0x7ff6f7220010}, me_txn = 0x7ff6dc10afd0,
> me_mapsize = 38654705664, me_size = 0, me_maxpg = 9437184, me_dbxs = 0x8eed10,
> me_dbflags = 0x8ceb40, me_txkey = 1, me_pgstate = {mf_pghead =
> 0x7ff6dc109d58, mf_pglast = 44},
> me_dpages = 0x0, me_free_pgs = 0xaf75e8, me_dirty_list =
> 0x7ffff721f010, me_maxfree_1pg = 509,
> me_nodemax = 2040}
>
>> -- Howard Chu
>> CTO, Symas Corp. http://www.symas.com
>> Director, Highland Sun http://highlandsun.com/hyc/
>> Chief Architect, OpenLDAP http://www.openldap.org/project/
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by nejasmicz＠gmail.com
On Thu, Oct 3, 2013 at 2:57 PM, <hyc(a)symas.com> wrote:
>
> Željko Nejašmić wrote:
> > On Wed, Oct 2, 2013 at 6:43 PM, <hyc(a)symas.com <mailto:hyc@symas.com>> wrote:
> > I ran the whole test suite for mdb, and as far as I can see, every test
> > returned OK.
> >
> > Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 firing
> > to openldap on RH 6.3:
> > ldapadd -h 172.17.101.150 -p 389 -D "cn=admin,dc=test" -w test -f test.ldif --
> > ldif file is the same as the previous ldclt command. Doubt it matters, but the
> > ldif file is 1M adds.
>
> Can you provide your slapd config and this LDIF?
LDIF file is just 1M adds of the following format:
dn: uid=XXXXXXX,ds=USERS,o=STANDARD,dc=spr
objectClass: sprUser
I've uploaded the config here: http://hastebin.com/nicecafaci.ldif
> > On the RH box:
> > - compiled openldap with -g -O0 and previously used flags
> > gdb `find /root/openldap/ -type d -printf '-d %p '` --args
> > /opt/openldap/libexec/slapd -h "ldap:/// ldapi:///" -F
> > /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap -d 0
> >
> > gdb output:
> > bt -- http://hastebin.com/hefikekaxi.sh
> > bt 10 full -- http://hastebin.com/vudocosuka.sh
>
> Can you also provide the gdb output for
> print *env
(gdb) print *env
$1 = {me_fd = 15, me_lfd = 14, me_mfd = 15, me_flags = 940113920,
me_psize = 4096,
me_maxreaders = 126, me_numreaders = 2, me_numdbs = 13, me_maxdbs =
130, me_pid = 43974,
me_path = 0x8c19a0 "/opt/openldap/var/openldap-data", me_map =
0x7ff6f721f000 "",
me_txns = 0x7ffff7ffb000, me_metas = {0x7ff6f721f010,
0x7ff6f7220010}, me_txn = 0x7ff6dc10afd0,
me_mapsize = 38654705664, me_size = 0, me_maxpg = 9437184, me_dbxs = 0x8eed10,
me_dbflags = 0x8ceb40, me_txkey = 1, me_pgstate = {mf_pghead =
0x7ff6dc109d58, mf_pglast = 44},
me_dpages = 0x0, me_free_pgs = 0xaf75e8, me_dirty_list =
0x7ffff721f010, me_maxfree_1pg = 509,
me_nodemax = 2040}
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 12 months
(ITS#7717) Sudden memory increase leading to Master LDAP crash
by marcon.bruno＠free.fr
Full_Name: Marcon Bruno
Version: 2.4.36
OS: Ubuntu
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (185.23.92.11)
Hi. We have deployed OpenLDAP on our system, using the following architecture :
One primary master
One failover master (mirror mode)
4 replicas
It works very well until the master LDAP receive two many writes /seconds. With
40 writes/seconds, the master LDAP work well about several minutes, then the
memory process (slapd) started to increase very quickly, about 20Mo/s !
When all memory and swap is consumed, the OS kill Slapd.
Notes :
- Even in disabling all overlays except syncprov, the problem persists
- If disabling only syncprov, there is no more problem
- If all slaves and mirror master are stopped, there is no more problem
This problem is very annoying. We are looking to a Microsoft solution, even if
we have already deployed our solution but obviously, we would like to keep an
OpenLDAP solution.
The problem is very easy to replay : one master and one slave are sufficient.
Then run 9 windows with a script adding an entry and modifying an entry.
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by hyc＠symas.com
Željko Nejašmić wrote:
> On Wed, Oct 2, 2013 at 6:43 PM, <hyc(a)symas.com <mailto:hyc@symas.com>> wrote:
> Without any other clues, this feels like ASLR is messing with us but that's
> just a wild guess. I can no longer reproduce the SIGBUS in slapd regardless of
> compile options, while ldclt itself keeps dying. If you can find some more
> reliable way to reproduce the issue that would help. Perhaps using the client
> in test060.
>
>
> I ran the whole test suite for mdb, and as far as I can see, every test
> returned OK.
>
> Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 firing
> to openldap on RH 6.3:
> ldapadd -h 172.17.101.150 -p 389 -D "cn=admin,dc=test" -w test -f test.ldif --
> ldif file is the same as the previous ldclt command. Doubt it matters, but the
> ldif file is 1M adds.
Can you provide your slapd config and this LDIF?
>
> On the RH box:
> - compiled openldap with -g -O0 and previously used flags
> gdb `find /root/openldap/ -type d -printf '-d %p '` --args
> /opt/openldap/libexec/slapd -h "ldap:/// ldapi:///" -F
> /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap -d 0
>
> gdb output:
> bt -- http://hastebin.com/hefikekaxi.sh
> bt 10 full -- http://hastebin.com/vudocosuka.sh
Can you also provide the gdb output for
print *env
>
> I am begging to doubt that the problem could be on my end as the bt seems to
> point to schema problems (although, I haven't analyzed it in great detail yet).
>
>
> Zeljko
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by nejasmicz＠gmail.com
--001a11c253c0f33b8604e7d59850
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wed, Oct 2, 2013 at 6:43 PM, <hyc(a)symas.com> wrote:
> hyc(a)symas.com wrote:
> > =C5=BDeljko Neja=C5=A1mi=C4=87 wrote:
> >> Here you go http://hastebin.com/fukecejuje.tex
> >
> > Interestingly enough, I got the same result as you on an initial
> compile/run
> > of slapd. Unfortunately, with optimization, the backtrace wasn't all th=
at
> > useful. Recompiling back-mdb with just -g, no optimization, gets a
> different
> > result though - slapd is fine, and ldclt dies with a heap corruption or
> > double-free.
>
> And now I cannot reproduce the original SIGBUS at all. But still getting
> various crashes in ldclt.
>
> ldclt -h localhost -p 9011 -D cn=3Dmanager,dc=3Dexample,dc=3Dcom -w secre=
t -b
> ou=3Dpeople,dc=3Dexample,dc=3Dcom -e
> object=3Dxx.txt,rdn=3D'uid:[A=3DINCRNNOLOOP(200000;999999;6)]' -e
> add,commoncounter
> -I 68
> ldclt version 4.23
> ldclt[30207]: Starting at Wed Oct 2 09:39:10 2013
>
> *** glibc detected *** ldclt: double free or corruption (fasttop):
> 0x00007fc2180021e0 ***
> =3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D
> /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fc223ff9b96]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x142d1)[0x7fc224f0b2d1]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x1ae74)[0x7fc224f11e74]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_Malloc+0x49)[0x7fc224f0d0b9]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x129f4)[0x7fc224f099f4]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(+0x12068)[0x7fc224f09068]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_vsmprintf+0x38)[0x7fc224f09b28]
> /usr/lib/x86_64-linux-gnu/libnspr4.so(PR_smprintf+0x8c)[0x7fc224f09bec]
> ldclt(+0x663a)[0x7fc22556663a]
> ldclt(+0x74a4)[0x7fc2255674a4]
> ldclt(+0x9d48)[0x7fc225569d48]
> ldclt(threadMain+0x329)[0x7fc2255735d9]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fc224341e9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc22406ecbd]
>
> Without any other clues, this feels like ASLR is messing with us but that=
's
> just a wild guess. I can no longer reproduce the SIGBUS in slapd
> regardless of
> compile options, while ldclt itself keeps dying. If you can find some mor=
e
> reliable way to reproduce the issue that would help. Perhaps using the
> client
> in test060.
I ran the whole test suite for mdb, and as far as I can see, every test
returned OK.
Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04
firing to openldap on RH 6.3:
ldapadd -h 172.17.101.150 -p 389 -D "cn=3Dadmin,dc=3Dtest" -w test -f test.=
ldif
-- ldif file is the same as the previous ldclt command. Doubt it matters,
but the ldif file is 1M adds.
On the RH box:
- compiled openldap with -g -O0 and previously used flags
gdb `find /root/openldap/ -type d -printf '-d %p '` --args
/opt/openldap/libexec/slapd -h "ldap:/// ldapi:///" -F
/opt/openldap/etc/openldap/slapd.d -g openldap -u openldap -d 0
gdb output:
bt -- http://hastebin.com/hefikekaxi.sh
bt 10 full -- http://hastebin.com/vudocosuka.sh
I am begging to doubt that the problem could be on my end as the bt seems
to point to schema problems (although, I haven't analyzed it in great
detail yet).
Zeljko
--001a11c253c0f33b8604e7d59850
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Oct 2, 2013 at 6:43 PM, <span dir=3D"ltr"><<a href=3D"m=
ailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">
<div><a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a> w=
rote:<br>
> =C5=BDeljko Neja=C5=A1mi=C4=87 wrote:<br>
>> Here you go <a href=3D"http://hastebin.com/fukecejuje.tex" target=
=3D"_blank">http://hastebin.com/fukecejuje.tex</a><br>
><br>
> Interestingly enough, I got the same result as you on an initial compi=
le/run<br>
> of slapd. Unfortunately, with optimization, the backtrace wasn't a=
ll that<br>
> useful. Recompiling back-mdb with just -g, no optimization, gets a dif=
ferent<br>
> result though - slapd is fine, and ldclt dies with a heap corruption o=
r<br>
> double-free.<br>
<br>
</div>And now I cannot reproduce the original SIGBUS at all. But still gett=
ing<br>
various crashes in ldclt.<br>
<div><br>
ldclt -h localhost -p 9011 -D cn=3Dmanager,dc=3Dexample,dc=3Dcom -w secret =
-b<br>
ou=3Dpeople,dc=3Dexample,dc=3Dcom -e<br>
object=3Dxx.txt,rdn=3D'uid:[A=3DINCRNNOLOOP(200000;999999;6)]' -e a=
dd,commoncounter<br>
-I 68<br>
ldclt version 4.23<br>
</div>ldclt[30207]: Starting at Wed Oct =C2=A02 09:39:10 2013<br>
<div><br>
*** glibc detected *** ldclt: double free or corruption (fasttop):<br>
</div>0x00007fc2180021e0 ***<br>
=3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fc223ff9b96]<br>
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x142d1)[0x7fc224f0b2d1]<br>
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x1ae74)[0x7fc224f11e74]<br>
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_Malloc+0x49)[0x7fc224f0d0b9]<br>
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x129f4)[0x7fc224f099f4]<br>
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x12068)[0x7fc224f09068]<br>
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_vsmprintf+0x38)[0x7fc224f09b28]<br=
>
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_smprintf+0x8c)[0x7fc224f09bec]<br>
ldclt(+0x663a)[0x7fc22556663a]<br>
ldclt(+0x74a4)[0x7fc2255674a4]<br>
ldclt(+0x9d48)[0x7fc225569d48]<br>
ldclt(threadMain+0x329)[0x7fc2255735d9]<br>
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fc224341e9a]<br>
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc22406ecbd]<br>
<br>
Without any other clues, this feels like ASLR is messing with us but that&#=
39;s<br>
just a wild guess. I can no longer reproduce the SIGBUS in slapd regardless=
of<br>
compile options, while ldclt itself keeps dying. If you can find some more<=
br>
reliable way to reproduce the issue that would help. Perhaps using the clie=
nt<br>
in test060.</blockquote><div><br></div><div>I ran the whole test suite for =
mdb, and as far as I can see, every test returned OK.</div><div><br></div><=
div>Found a new way to reproduce the SIGBUS using ldapadd on Ubuntu 12.04 f=
iring to openldap on RH 6.3:<br>
</div><div>ldapadd -h 172.17.101.150 -p 389 -D "cn=3Dadmin,dc=3Dtest&q=
uot; -w test -f test.ldif -- ldif file is the same as the previous ldclt co=
mmand. Doubt it matters, but the ldif file is 1M adds.</div></div><br></div=
>
<div class=3D"gmail_extra">On the RH box:</div><div class=3D"gmail_extra">-=
compiled openldap with -g -O0 and previously used flags</div><div class=3D=
"gmail_extra">
gdb `find /root/openldap/ -type d -printf '-d %p '` --args /opt/ope=
nldap/libexec/slapd -h "ldap:/// ldapi:///" -F /opt/openldap/etc/=
openldap/slapd.d -g openldap -u openldap -d 0<br></div><div class=3D"gmail_=
extra">
<br></div><div class=3D"gmail_extra">gdb output:</div><div class=3D"gmail_e=
xtra">bt --=C2=A0<a href=3D"http://hastebin.com/hefikekaxi.sh" target=3D"_b=
lank">http://hastebin.com/hefikekaxi.sh</a></div><div class=3D"gmail_extra"=
>bt 10 full --=C2=A0<a href=3D"http://hastebin.com/vudocosuka.sh" target=3D=
"_blank">http://hastebin.com/vudocosuka.sh</a></div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I am beggin=
g to doubt that the problem could be on my end as the bt seems to point to =
schema problems (although, I haven't analyzed it in great detail yet).<=
/div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">Zeljko</div>
</div>
--001a11c253c0f33b8604e7d59850--
9 years, 12 months
Re: (ITS#7715) SIGBUS when mdb is configured with writemap
by hyc＠symas.com
hyc(a)symas.com wrote:
> Željko Nejašmić wrote:
>> Here you go http://hastebin.com/fukecejuje.tex
>
> Interestingly enough, I got the same result as you on an initial compile/run
> of slapd. Unfortunately, with optimization, the backtrace wasn't all that
> useful. Recompiling back-mdb with just -g, no optimization, gets a different
> result though - slapd is fine, and ldclt dies with a heap corruption or
> double-free.
And now I cannot reproduce the original SIGBUS at all. But still getting
various crashes in ldclt.
ldclt -h localhost -p 9011 -D cn=manager,dc=example,dc=com -w secret -b
ou=people,dc=example,dc=com -e
object=xx.txt,rdn='uid:[A=INCRNNOLOOP(200000;999999;6)]' -e add,commoncounter
-I 68
ldclt version 4.23
ldclt[30207]: Starting at Wed Oct 2 09:39:10 2013
*** glibc detected *** ldclt: double free or corruption (fasttop):
0x00007fc2180021e0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7fc223ff9b96]
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x142d1)[0x7fc224f0b2d1]
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x1ae74)[0x7fc224f11e74]
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_Malloc+0x49)[0x7fc224f0d0b9]
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x129f4)[0x7fc224f099f4]
/usr/lib/x86_64-linux-gnu/libnspr4.so(+0x12068)[0x7fc224f09068]
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_vsmprintf+0x38)[0x7fc224f09b28]
/usr/lib/x86_64-linux-gnu/libnspr4.so(PR_smprintf+0x8c)[0x7fc224f09bec]
ldclt(+0x663a)[0x7fc22556663a]
ldclt(+0x74a4)[0x7fc2255674a4]
ldclt(+0x9d48)[0x7fc225569d48]
ldclt(threadMain+0x329)[0x7fc2255735d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7fc224341e9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7fc22406ecbd]
Without any other clues, this feels like ASLR is messing with us but that's
just a wild guess. I can no longer reproduce the SIGBUS in slapd regardless of
compile options, while ldclt itself keeps dying. If you can find some more
reliable way to reproduce the issue that would help. Perhaps using the client
in test060.
> All subsequent runs give the same result. Still looking into this; getting
> away from the Ubuntu bundled libldap will probably help.
>>
>>
>> Zeljko
>>
>>
>> On Wed, Oct 2, 2013 at 11:34 AM, <hyc(a)symas.com <mailto:hyc@symas.com>> wrote:
>>
>> nejasmicz(a)gmail.com <mailto:nejasmicz@gmail.com> wrote:
>> > Full_Name: Željko Nejašmić
>> > Version: latest git pull of OPENLDAP_REL_ENG_2_4
>> > OS: RedHat 6.3
>> > URL:
>> > Submission from: (NULL) (213.147.123.33)
>> >
>>
>> > Hardware underneath all of that is:
>> > 1) HP ProLiant BL460c Gen8, dual Xeon E5-2658 with attached
>> storage blade
>> > D2200sb with SSD raid, 256GB RAM -- RedHat 6.3 tests
>> > 2) Intel server blade S2400BB, dual Xeon E5-2403, 48GB RAM --
>> Ubuntu 12.04
>> > tests
>> >
>> > If anything more is required to assist you in troubleshooting, please
>> let me
>> > know.
>>
>> Can you also post the gdb output for "bt 5 full" ?
>> >
>> >
>> > Zeljko
>> >
>> >
>>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years