The crash occurs because of derefencing a null pointer but may also trigger a invalid access to random memory
(gdb) where #0 0x00007f199bd72677 in mr_wrap_mr_index_sv_fn (pb=<optimized out>) at ldap/servers/slapd/plugin_mr.c:296 #1 0x00007f198f0134d5 in matchrule_values_to_keys_sv (pb=0x7f195803f220, input_values=input_values@entry=0x7f1958035cf0, output_values=output_values@entry=0x7f19537fd730) at ldap/servers/slapd/back-ldbm/matchrule.c:163 #2 0x00007f198efe3211 in index_addordel_values_ext_sv (be=be@entry=0x55d3722ebee0, type=<optimized out>, vals=0x7f1958035cf0, evals=evals@entry=0x0, id=35, flags=flags@entry=1, txn=0x7f19537fdc30, idl_disposition=0x0, buffer_handle=0x0) at ldap/servers/slapd/back-ldbm/index.c:2145 #3 0x00007f198efe3ae1 in index_addordel_values_sv (be=be@entry=0x55d3722ebee0, type=<optimized out>, vals=<optimized out>, evals=evals@entry=0x0, id=<optimized out>, flags=flags@entry=1, txn=0x7f19537fdc30) at ldap/servers/slapd/back-ldbm/index.c:1981 #4 0x00007f198f00ffae in ldbm_back_ldbm2index (pb=<optimized out>) at ldap/servers/slapd/back-ldbm/ldif2ldbm.c:2285 #5 0x00007f199bd998f1 in task_index_thread (arg=0x55d37a101910) at ldap/servers/slapd/task.c:1652 #6 0x00007f1999f3d5cb in _pt_root () from /lib64/libnspr4.so #7 0x00007f19998dc60a in start_thread () from /lib64/libpthread.so.0 #8 0x00007f1999616a4d in clone () from /lib64/libc.so.6 (gdb) frame #0 0x00007f199bd72677 in mr_wrap_mr_index_sv_fn (pb=<optimized out>) at ldap/servers/slapd/plugin_mr.c:296 296 mrpriv->sva = out_vals; /* save pointer for later */ (gdb) list 295 290 slapi_pblock_get(pb, SLAPI_PLUGIN_MR_VALUES, &in_vals); 291 (*pi->plg_mr_values2keys)(pb, in_vals, &out_vals, ftype); 292 slapi_pblock_set(pb, SLAPI_PLUGIN_MR_KEYS, out_vals); 293 /* we have to save out_vals to free next time or during destroy */ 294 slapi_pblock_get(pb, SLAPI_PLUGIN_OBJECT, &mrpriv); 295 mr_private_indexer_done(mrpriv); /* free old vals, if any */ 296 mrpriv->sva = out_vals; /* save pointer for later */ 297 rc = 0; 298 } 299 return rc; (gdb) print mrpriv $12 = (struct mr_private *) 0x0 (gdb) up #1 0x00007f198f0134d5 in matchrule_values_to_keys_sv (pb=0x7f195803f220, input_values=input_values@entry=0x7f1958035cf0, output_values=output_values@entry=0x7f19537fd730) at ldap/servers/slapd/back-ldbm/matchrule.c:163 163 mrINDEX (pb); (gdb) print pb->pb_mr_type $13 = 0x7f19537fd9f0 "krbPrincipalName" (gdb) print pb->pb_mr_oid $14 = 0x55d3723af700 "caseExactIA5Match"
The problem is that SLAPI_PLUGIN_OBJECT is assumed to be set and in some cases it is not. Note that mr_private_indexer_done checks that SLAPI_PLUGIN_OBJECT is set before using it. If it is normal that it is not systematically set the fix would:
if (mpriv) mrpriv->sva = out_vals;
The code has been there since this patch: {{{ commit ca6e653 wrap new style matching rule plugins for use in old style indexing code Create wrappers for the new syntax plugin style matching rule code so that we can use the old matching rule indexing functions. Introduced a new type of indexer for Slapi_Value values. The old style used struct berval * values, but the syntax plugins and a lot of newer code work with Slapi_Value* instead. }}} I think your adding mpriv check is a good approach.
Please note that there are 2 places to "save pointer", one is in mr_wrap_mr_index_sv_fn and another in mr_wrap_mr_index_fn. :)
I reproduced the crash and I think it is somehow related to https://fedorahosted.org/389/ticket/48497
In fact, when an extended search occurs before the indexing. It remains a defined matching rules and default_mr_indexer_create is not called. This is in that function that the mrprivate is set in pblock(SLAPI_PLUGIN_OBJECT).
I reproduced the crash systematically if I do an extended search before the indexing.
attachment 0001-Ticket-48746-Crash-when-indexing-an-attribute-with-a.patch
attachment ticket48746_test.py
attachment 0002-Ticket-48746-Crash-when-indexing-an-attribute-with-a.patch
Thanks Rich for this large review
'''Master'''
Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 4.98 KiB, done. Total 11 (delta 8), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git b9dd886..dde5b62 master -> master
commit dde5b62 Author: Thierry Bordaz tbordaz@redhat.com Date: Wed Mar 2 18:13:41 2016 +0100
'''1.3.4'''
Counting objects: 19, done. Delta compression using up to 4 threads. Compressing objects: 100% (11/11), done. Writing objects: 100% (11/11), 5.11 KiB, done. Total 11 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 70670f2..cba64d1 389-ds-base-1.3.4 -> 389-ds-base-1.3.4
commit cba64d1 Author: Thierry Bordaz tbordaz@redhat.com Date: Wed Mar 2 18:13:41 2016 +0100
Metadata Update from @nhosoi: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.4.9
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/1806
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.