(ITS#8263) Broken cursor tracking in mdb_cursor_put()
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: mdb.master, 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52
OS: Linux x86_64
URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151005.c
Submission from: (NULL) (81.191.45.5)
Submitted by: hallvard
The test program catches several cursor tracking bugs.
$ ./a.out 250
mn_flags = 0
mn_flags = 4
mn_flags = 4
a.c:36: run: Assertion `d1.mv_size == ksz && d1.mv_data == d2.mv_data' failed.
Aborted
$ ./a.out 500
mn_flags = 0
mn_flags = 4
mn_flags = 6
a.c:36: run: Assertion `d1.mv_size == ksz && d1.mv_data == d2.mv_data' failed.
Aborted
$ ./a.out 1000
mn_flags = 0
mn_flags = 6
a.c:34: mdb_cursor_get(c1, &k1, &d1, MDB_GET_CURRENT): Invalid argument
Aborted
It works when the DUPSORT sub-DB is created immediately:
$ ./a.out 1500
mn_flags = 6 <repeated 22 times>
7 years, 7 months
Re: (ITS#8258) LMDB cursor_del followed by MDB_NEXT can trigger assert crash
by hyc＠symas.com
hyc(a)symas.com wrote:
> steven.lang(a)hgst.com wrote:
>> Full_Name: Steven Lang
>> Version: LMDB 0.9.16
>> OS: Ubuntu 14.04
>> URL: ftp://ftp.openldap.org/incoming/steven-lang-150929.c
>> Submission from: (NULL) (199.255.44.5)
>>
>>
>> While doing some testing using randomized key and data lengths and random puts
>> and deletes, I found a situation in which mdb_cursor_del(...) followed by
>> mdb_cursor_get(..., MDB_NEXT) causes an error:
>>
>> mdb.c:5726: Assertion 'IS_LEAF(mp)' failed in mdb_cursor_next()
>> Aborted
>> Attached is a program which fills a DB, then deletes keys until it asserts.
>
> Thanks for the report. Our alternate approach to solve #8221 was to check the
> page fill factor including the (usually omitted) key #0 size; we didn't go
> that way because it was slightly more processing. But given this bug, it seems
> that's the only way to go.
>
Fixed now in git, thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 7 months
Re: (ITS#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by hyc＠symas.com
hguo(a)suse.com wrote:
> This message is in MIME format. The first part should be readable text,
> while the remaining parts are likely unreadable without MIME-aware tools.
Only plaintext emails should be used here.
>
> ---1609925821-2101104869-1443783301=:2873
> Content-Type: text/plain; charset=UTF-8; format=flowed
> Content-Transfer-Encoding: 8BIT
>
> Hello Michael.
>
> The bug can be triggered not only on master, but on the released versions 2.4.41 and 2.4.42 as well.
test062 is not included in OpenLDAP 2.4. Running it against 2.4 is invalid.
This is a dup of ITS#7639. Closing this ITS.
> Regards,
> Howard
>
> On Thu, 1 Oct 2015, Michael Ströder wrote:
>
>> Howard,
>>
>> hguo(a)suse.com wrote:
>>> The test case "test062-config-delete" occasionally runs into segfault when
>>> running with BDB backend. The chance of segfault happening is about once every
>>> 200 runs.
>>>
>>> The version of OpenLDAP is post-2.4.42 master checked out at revision
>>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make.
>>
>> To me this revision seems to be from master branch. Are you sure you want to
>> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch?
>>
>> Also note that back-bdb is highly deprecated and IIRC building it will be
>> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to).
>>
>> Ciao, Michael.
>> .
>>
> ---1609925821-2101104869-1443783301=:2873--
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 8 months
Re: (ITS#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by leo＠yuriev.ru
This issue fixed in ReOpenLDAP.
https://github.com/ReOpen/ReOpenLDAP/issues/45
2015-10-02 13:55 GMT+03:00 <hguo(a)suse.com>:
> This message is in MIME format. The first part should be readable text=
,
> while the remaining parts are likely unreadable without MIME-aware tool=
s.
>
> ---1609925821-2101104869-1443783301=3D:2873
> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed
> Content-Transfer-Encoding: 8BIT
>
> Hello Michael.
>
> The bug can be triggered not only on master, but on the released versions=
2.4.41 and 2.4.42 as well.
>
> Regards,
> Howard
>
> On Thu, 1 Oct 2015, Michael Str=C3=B6der wrote:
>
>> Howard,
>>
>> hguo(a)suse.com wrote:
>>> The test case "test062-config-delete" occasionally runs into segfault w=
hen
>>> running with BDB backend. The chance of segfault happening is about onc=
e every
>>> 200 runs.
>>>
>>> The version of OpenLDAP is post-2.4.42 master checked out at revision
>>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make.
>>
>> To me this revision seems to be from master branch. Are you sure you wan=
t to
>> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 br=
anch?
>>
>> Also note that back-bdb is highly deprecated and IIRC building it will b=
e
>> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading t=
o).
>>
>> Ciao, Michael.
>> .
>>
> ---1609925821-2101104869-1443783301=3D:2873--
>
>
>
7 years, 8 months
Re: (ITS#8260) Test "test062-config-delete" occasionally runs intosegmentation fault
by hguo＠suse.com
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
---1609925821-2101104869-1443783301=:2873
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
Hello Michael.
The bug can be triggered not only on master, but on the released versions 2.4.41 and 2.4.42 as well.
Regards,
Howard
On Thu, 1 Oct 2015, Michael Ströder wrote:
> Howard,
>
> hguo(a)suse.com wrote:
>> The test case "test062-config-delete" occasionally runs into segfault when
>> running with BDB backend. The chance of segfault happening is about once every
>> 200 runs.
>>
>> The version of OpenLDAP is post-2.4.42 master checked out at revision
>> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make.
>
> To me this revision seems to be from master branch. Are you sure you want to
> test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch?
>
> Also note that back-bdb is highly deprecated and IIRC building it will be
> disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to).
>
> Ciao, Michael.
> .
>
---1609925821-2101104869-1443783301=:2873--
7 years, 8 months
(ITS#8262) libldap API enhancement
by hyc＠openldap.org
Full_Name: Howard Chu
Version: 2.4
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (70.211.141.184)
Submitted by: hyc
libldap has always (since initial commit) had an ldap_build_search_request()
function which constructs the ber of the request message. This ber can then be
sent to a server using ldap_send_initial_request().
Corresponding build* functions are missing for all of the other request types.
There doesn't appear to be a good reason for this inconsistency, and it would be
useful to be able to handle all request types the same way. In particular, it's
useful for a caller to know the messageID of the new request before attempting
to send it over the wire. This would make a number of issues in
back-ldap/back-meta easier to deal with.
7 years, 8 months
(ITS#8261) sl_malloc API enhancement
by hyc＠openldap.org
Full_Name: Howard Chu
Version: 2.4
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (70.211.141.184)
Submitted by: hyc
The slap_sl_mem_detach() function has never been used. It's basically not useful
as-is, but a more general function slap_sl_mem_setctx would be useful, and could
also handle any potential use cases for _mem_detach.
7 years, 8 months
Re: (ITS#8260) Test "test062-config-delete" occasionally runs into segmentation fault
by michael＠stroeder.com
Howard,
hguo(a)suse.com wrote:
> The test case "test062-config-delete" occasionally runs into segfault when
> running with BDB backend. The chance of segfault happening is about once every
> 200 runs.
>
> The version of OpenLDAP is post-2.4.42 master checked out at revision
> 94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make.
To me this revision seems to be from master branch. Are you sure you want to
test that? Or are you rather looking for testing OPENLDAP_REL_ENG_2_4 branch?
Also note that back-bdb is highly deprecated and IIRC building it will be
disabled in OpenLDAP 2.5 (which is AFAIK what master branch is heading to).
Ciao, Michael.
7 years, 8 months
(ITS#8260) Test "test062-config-delete" occasionally runs into segmentation fault
by hguo＠suse.com
Full_Name: Howard Guo
Version: master-94d6581b50fa2d877cf4a1e20ca6766454094ef8
OS: openSUSE
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (195.135.221.2)
The test case "test062-config-delete" occasionally runs into segfault when
running with BDB backend. The chance of segfault happening is about once every
200 runs.
The version of OpenLDAP is post-2.4.42 master checked out at revision
94d6581b50fa2d877cf4a1e20ca6766454094ef8, simply compiled with make.
The operating system is openSUSE Tumbleweed running on kernel 4.1.6.
Here is the GDB conversation with a captured core dump file:
Core was generated by
`/home/howard/qa_test_openldap2/tests/../servers/slapd/slapd -s0 -F ./slapd.d
-h'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000055e606fed253 in syncprov_op_abandon (op=0x7f7aa15498a0,
rs=0x7f7aa15496e0) at syncprov.c:1156
1156 if ( so->s_op->o_connid == op->o_connid &&
(gdb) l
1151 syncprov_info_t *si = on->on_bi.bi_private;
1152 syncops *so, **sop;
1153
1154 ldap_pvt_thread_mutex_lock( &si->si_ops_mutex );
1155 for ( sop=&si->si_ops; (so = *sop); sop = &(*sop)->s_next ) {
1156 if ( so->s_op->o_connid == op->o_connid &&
1157 so->s_op->o_msgid == op->orn_msgid ) {
1158 so->s_op->o_abandon = 1;
1159 *sop = so->s_next;
1160 break;
(gdb) info locals
on = <optimized out>
si = 0x7f7a94104990
so = 0x7f7a94103f30
sop = 0x7f7a94104990
(gdb) print so->s_op->o_hdr
Cannot access memory at address 0x6172757463757274
Please let me know how I may assist further with debugging.
7 years, 8 months
