Description of problem: Acceptance testing reported failures in the following test suites, that use matching rules: I18n (Data Comparison, cases tp2, tp3) Filters (Bitwise filters, cases 06-24) This regression was introduced in https://fedorahosted.org/389/ticket/48746 If I revert https://fedorahosted.org/389/attachment/ticket/48746/0002-Ticket-48 746-Crash-when-indexing-an-attribute-with-a.patch, those tests pass. Version-Release number of selected component (if applicable): 389-ds-base-1.3.5.3-1.el7.x86_64
The fix for 48746 (https://fedorahosted.org/389/attachment/ticket/48746/0002-Ticket-48746-Crash-when-indexing-an-attribute-with-a.patch), changes plugin_mr_filter_create.
In this function, it tries to retrieve an already registered plugin that handle the matching rule. If no registered plugin, it then loop over all the enabled plugin to find one. It is failing to retrieve it although the plugin is enabled.
the server supports two styles of MR plugins: old styles (bitwise, collation) registers only the SLAPI_PLUGIN_MR_FILTER_CREATE_FN or SLAPI_PLUGIN_MR_INDEXER_CREATE_FN functions. These functions are responsible to check if they support the MR name or oid when creating an index/filter new style (cis, ces, bin..) calls syntax_matching_rule_plugin_init that in addition registers the OIDs and Names supported by the MR. Then call to plugin_mr_find(OID/NAME) checks if the plugin supports the OID or NAME.
Fix https://fedorahosted.org/389/ticket/48746 broke the compatibility with old styles MR plugins because it systematically calls plugin_mr_find.
From the fix https://fedorahosted.org/389/ticket/48746, keeping only the hardening part prevents the crash 48746 and fixes 48844.
It remains an second part of the fix 48746, that prevented https://fedorahosted.org/389/ticket/48745. Still working on this second part
attachment 0001-Ticket-48844-Regression-introduced-in-matching-rules.patch
attachment ticket48844_test.py
Good morning,
For the test case, you have many filters with F<int> at the top of the file. But not all of them are used. Are these there for a reason?
As well, would it be worth giving them more descriptive names?
Otherwise, the code applies, test passes, and doesn't set off any of my checks. I'm happy to ack, if you want to change the test case, let me know,
Thanks William for the review. The test case was taken from parts of filter suite done by lkrispen and I did not clean immediately. I cleaned it and add some comments in the test case.
'''git push origin master''' Counting objects: 10, done. Delta compression using up to 8 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 3.80 KiB | 0 bytes/s, done. Total 10 (delta 7), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git 03c1e86..7ebc170 master -> master
commit 7ebc170 Author: Thierry Bordaz tbordaz@redhat.com Date: Thu May 19 15:45:26 2016 +0200
Metadata Update from @tbordaz: - Issue assigned to tbordaz - Issue set to the milestone: 1.3.5.5
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/1904
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.