https://bugs.openldap.org/show_bug.cgi?id=9258
Bug ID: 9258
Summary: Segmentation fault with -u option
Product: OpenLDAP
Version: 2.5
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nick(a)folino.us
Target Milestone: ---
starting as root and using the -u option causes segfault:
$ sudo /apps/openldap-devel/libexec/slapd -h "ldap://localhost" -f
/apps/openldap-devel/etc/openldap/slapd.conf -u nick -d -1
ldap_url_parse_ext(ldap://localhost/)
ldap_init: trying /apps/openldap-devel/etc/openldap/ldap.conf
ldap_init: using /apps/openldap-devel/etc/openldap/ldap.conf
ldap_init: HOME env is /root
ldap_init: trying /root/ldaprc
ldap_init: trying /root/.ldaprc
ldap_init: trying ldaprc
ldap_init: LDAPCONF env is NULL
ldap_init: LDAPRC env is NULL
5eb7fbed @(#) $OpenLDAP: slapd 2.5.X (May 10 2020 08:03:33) $
nick@opti790:/home/nick/git/openldap/servers/slapd
ldap_pvt_gethostbyname_a: host=opti790, r=0
5eb7fbed daemon_init: ldap://localhost
5eb7fbed daemon_init: listen on ldap://localhost
5eb7fbed daemon_init: 1 listeners to open...
ldap_url_parse_ext(ldap://localhost)
5eb7fbed daemon: listener initialized ldap://localhost
5eb7fbed daemon_init: 1 listeners opened
munmap_chunk(): invalid pointer
Aborted
Starting as the user without the -u option loads slapd without issue
This also fails in the 2.X branch
Works as intended in 2.4.50.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6937
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nick(a)folino.us
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
*** Bug 9258 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=6937
--- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
commit fc8a7b25b8b5da95ce11743cc2386b257af26923
Author: Ryan Tandy <ryan(a)nardis.ca>
Date: Sun May 10 08:47:54 2020 -0700
ITS#9258 More for ITS#6937, don't free user/group
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8847
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|quanah(a)openldap.org |bugs(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8758
--- Comment #4 from mirror(a)koddos.net <mirror(a)koddos.net> ---
Hello Quanah,
It is setup:
https://mirror.koddos.net/OpenLDAP/ (Netherlands)
https://mirror-hk.koddos.net/OpenLDAP/ (Hong Kong)
Regards,
Martin
> https://bugs.openldap.org/show_bug.cgi?id=8758
>
> --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
> (In reply to mirror(a)koddos.net from comment #2)
>> Hello,
>>
>> Yes we still are interested. We run mirrors in Hong Kong and the
>> Netherlands. We can setup both locations if you wish.
> Hi Martin,
>
> That sounds great. The server for rsync is www.openldap.org and the module
> name is OpenLDAP-ftp
>
> Let me know the links to the mirrors they are configured and I will add them to
> the website.
>
> Regards,
> Quanah
>
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9098
--- Comment #18 from maxime.besson(a)worteks.com <maxime.besson(a)worteks.com> ---
Hi,
In thread 1 at #4 :
i and candidates[i] are optimized out, but the disasembly if that assert line
shows a 0x10(%r13),%eax that leads me to believe that candidates[i] is in $r13
at that time:
(gdb) print *((SlapReply *)$r13)
$90 = {sr_type = REP_RESULT, sr_tag = 3, sr_msgid = -1, sr_err = 0, sr_matched
= 0x0, sr_text = 0x0, sr_ref = 0x0,
sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0,
r_operational_attrs = 0x0, r_attrs = 0x0,
r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0},
sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}},
sr_flags = 0}
I can't be exactly sure about 'i', but poking around memory makes be believe
that it's 5 too.
In thread 8 at #9:
(gdb) print candidate
$85 = 5
(gdb) print candidates[candidate]
$86 = {sr_type = 4294967295, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched =
0x0, sr_text = 0x0, sr_ref = 0x25,
sr_ctrls = 0x7f007061646c, sr_un = {sru_search = {r_entry = 0x7f4184000078,
r_attr_flags = 32,
r_operational_attrs = 0x25, r_attrs = 0x7f005f706374, r_nentries =
-2078873856, r_v2ref = 0x20}, sru_sasl = {
r_sasldata = 0x7f4184000078}, sru_extended = {r_rspoid = 0x7f4184000078
"\320|\033\204A\177", r_rspdata = 0x20}},
sr_flags = 133}
The other stack traces I collected however do not seem to show an interaction
with ldap_sasl_bind
I should be able to deploy a patched slapd 2.4.48 (or why not 2.4.49) if you
send me a diff.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9098
--- Comment #17 from nivanova(a)symas.com <nivanova(a)symas.com> ---
Hello again,
We have tried to reproduce the issue, but so far without success - with or
without timeouts, and running with helgrind did not show any relevant errors.
We will keep trying, but in the mean time:
The trace you provided shows something curious. We have the assertion error in
Thread 1, and at the same time, we have Thread 8 performing ldap_sasl_bind on
the same mc. It could be on a different candidate, in which case this would be
irrelevant, but to make sure - if you still have the core and are able to open
it, can you give us the following:
In thread 1 at #4 , the value of i and of candidates[i]
In thread 8 at #9, the value of candidate and candidates[candidate]
It also seems something strange has happened to the data, entry values are
different from the current, and the pointers seem off...
We may need to add a few additional log messages to check the flow and data
state since we can't debug. Given that you also can't reproduce it in a test
environment, how feasible would be to deploy a build in production that has
only log messages added?
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8282
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=8282
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
commit 86b78c87f48a7203893214d4fcbc1894c4eb338d
Author: Quanah Gibson-Mount <quanah(a)openldap.org>
Date: Wed May 6 21:51:22 2020 +0000
ITS#8282 - Update tools page
- Fix link to autoconf
- Fix link to libtool
- Add link to gcc
- Add link to MSYS2
commit d867b164c5e69e49bc13677c6ff541abae10bb81
Author: Quanah Gibson-Mount <quanah(a)openldap.org>
Date: Wed May 6 19:34:20 2020 +0000
Update tools page to be current
--
You are receiving this mail because:
You are on the CC list for the bug.