On 01/16/2014 03:14 PM, Deas, Jim wrote: > Rich, > > Thanks. I actually did have the address of operator on the code. Both > the init and config are defining only a couple of specific functions > (start_fn, pre_results_fn,pre_abandon_fn) one function defined for each. > > The one I am testing is preop_results() which does trigger, works as > you suggested below, but crashes when adding a call to > slapi_entry_attr_find() for many but not all remote inquiries. In the code you shared, you are setting "e" with this call: slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &e) The issue here is that "e" is a Slapi_Entry, but SLAPI_SEARCH_ATTRS doesn't retreive a Slapi_Entry from the pblock. This means "e" is incorrect at this point (it will likely have bad pointer values if you look into it in gdb). When you call slapi_entry_attr_find(), it is likely trying to dereference some of these bad pointer values, which leads to the crash. You need to pass a valid Slapi_Entry to this function (if you even need this function). What exactly are you trying to have your plug-in do? Thanks, -NGK > > Perhaps I am going at this all wrong. What sequence should I call to get > a multivariable attribute? In this case a list of attribute ‘memberUid’ > while rejecting preop_results not directed at returning Group information? > > > > JD > > > > *From:*389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx > [mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] *On Behalf Of *Rich > Megginson > *Sent:* Thursday, January 16, 2014 2:25 PM > *To:* 389 Directory server developer discussion. > *Subject:* Re: [389-devel] plugin problem using slapi_entry_attr_find > > > > Another bug in your code. The argument for SLAPI_SEARCH_ATTRS should be > the address of a char **.e.g. > > { > char **attrs; > int ii = 0; > ... > if (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &attrs) !=0 )return (-1); > for (ii = 0; attrs && attrs[ii]; ++ii) { > slapi_log_error(SLAPI_LOG_PLUGIN, "my plugin", > "search attr %d is %s\n", ii, attrs[ii]); > } > ... > > In your plugin entry and in your plugin config you specify which types > of operations (bind, search, add, etc.) your plugin will handle. > E.g. a SLAPI_PLUGIN_PRE_BIND_FN will be called at the pre-operation > stage of a BIND operation. > > Each type of plugin will have possibly different pblock parameters > available. So, for example, if you use the same function as both a bind > preop and a search preop - when called as a bind preop, the > SLAPI_SEARCH_ATTRS will not be available. > > If you want to use the same function for different op types, declare > different functions for each op type, then call your common function > with the op type, like this: > > int > bind_preop(Slapi_PBlock *pb) { > return common_function(SLAPI_PLUGIN_PRE_BIND_FN, pb); > } > > int > search_preop(Slapi_PBlock *pb) { > return common_function(SLAPI_PLUGIN_PRE_SEARCH_FN, pb); > } > ... > > int > common_function(int type, Slapi_PBlock *pb) { > ... > if (type == SLAPI_PLUGIN_PRE_BIND_FN) { > do some bind specific action > } else if (type == SLAPI_PLUGIN_PRE_SEARCH_FN) { > do some search specific action > } > ... > > On 01/16/2014 03:02 PM, Deas, Jim wrote: > > On further review it appears that the line in question will crash > Dirsrv on some request from PAM or even 389-Console but not when > searching groups via ldapsearch > > Should there be a statement that determines what type of query > triggered the preop_result so I know if it’s proper to look for > attributes? > > > > > > *From:*389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx > <mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx> > [mailto:389-devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx] *On Behalf Of > *Rich Megginson > *Sent:* Thursday, January 16, 2014 11:29 AM > *To:* 389 Directory server developer discussion. > *Subject:* Re: [389-devel] plugin problem using slapi_entry_attr_find > > > > On 01/16/2014 11:39 AM, Deas, Jim wrote: > > My bet, a rookie mistake. Am I forgetting to init a pointer etc??? > > Adding the line surrounded by ****** in this routine makes > dirsrv unstable and crashes it after a few queries. > > > > > > > > > > /* Registered preop_result routine */ > > int gnest_preop_results( Slapi_PBlock *pb){ > > Slapi_Entry *e; > > Slapi_Attr **a; > > This should be Slapi_Attr *a; > > > > > If (slapi_pblock_get( pb, SLAPI_SEARCH_ATTRS, &e) !=0 )return (-1); > > > > /*****************This line makes the server unstable and crashes it > after one or two queries ********************/ > > If(slapi_entry_attr_find(e, “memberUid”,&a) == 0) > slapi_log_error(SLAPI_LOG_PLUGIN, “gnest preop”,”memberUid found in > record); > > /******************************************************************************************************/ > > > > > > Return (0); > > } > > > > *JD* > > > > > > > > -- > > 389-devel mailing list > > 389-devel@xxxxxxxxxxxxxxxxxxxxxxx <mailto:389-devel@xxxxxxxxxxxxxxxxxxxxxxx> > > https://admin.fedoraproject.org/mailman/listinfo/389-devel > > > > > > > -- > > 389-devel mailing list > > 389-devel@xxxxxxxxxxxxxxxxxxxxxxx <mailto:389-devel@xxxxxxxxxxxxxxxxxxxxxxx> > > https://admin.fedoraproject.org/mailman/listinfo/389-devel > > > > > > -- > 389-devel mailing list > 389-devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-devel > -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
