Full_Name: Peter Watkins Version: 2.0.11 OS: Solaris 2.6 URL: Submission from: (NULL) (208.252.129.98) Our schema defines an optional numeric atttribute (EQUALITY numericStringMatch, SUBSTR numericStringSubstringsMatch). I am trying to search for objects by that attribute, with this code ldap_search_ext_s( ldap, BASE, SCOPE, filter, attribs, 0, NULL, NULL, LDAP_MSG_ONE, 0, &result) Thepreceding ldap_init() and ldap_simple_bind_s() work fine. If filter is "(attrName=*)" then the search works (returns no data, but likely because I've specified LDAP_MSG_ONE). But if filter looks like "(attrName=1234)" then slapd dumps core. Here's the last few lines that I see in "-d 9" debug mode: send_ldap_result: conn=0 op=0 p=2 send_ldap_response: msgid=1 tag=97 err=0 ber_flush: 14 bytes to sd 8 daemon: activity on 1 descriptors daemon: activity on: 8r daemon: read activity on 8 connection_get(8): got connid=0 connection_read(8): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 295 contents: deferring operation ber_get_next ber_get_next on fd 8 failed errno=11 (Resource temporarily unavailable) daemon: select: listen=7 active_threads=1 tvp=NULL do_search ber_scanf fmt ({aiiiib) ber: ber_scanf fmt ({oo}) ber: Assertion failed: newval->bv_val < p, file schema_init.c, line 3221 This failed assertion sounds a lot like what is reported in this message: http://www.openldap.org/lists/openldap-bugs/200008/msg00023.html My guess is that assert( newval->bv_val < p ); on line 3221 of schema_init.c really should be assert( newval->bv_val <= p ); because if the last char in val (as passed to numericStringNormalize()) is not one recognized as whitespace by ASCII_SPACE, then at line 3221, newval->bv_val and p should point at the same address space. Testing, this seems right. If I search for "(attrName=1234 )" (note the trailing space), then everything works beautifully, and I get my desired results. Even if "(attrName=1234)" were an illegal filter, and I doun't think it is, there's no reason slapd should dump core. I'll make the change in our code over here, but appreciate feedback on whether I've got this right. (And thank you all for your work on this project!) -Peter
Quick notes I was unable to add to the ITS ticket: - suggested fix does not work because... - isn't (q <= p) an assertion about logical memory addresses? - does it mean to assert something like newval->bv_val being no shorter than val->bv_val - which would be "assert( (q - newval->bv_val) <= (p - val->bv_val) );", right? That assertion *instead* of the two current assertions, right? - shouldn't the code ensure that the ch_malloc() calls succeeded? Thanks, -Peter
At 10:11 AM 7/24/2001, Peter W wrote: >Quick notes I was unable to add to the ITS ticket: >- suggested fix does not work because... >- isn't (q <= p) an assertion about logical memory addresses? Yes, it looks like someone (me?) copied some code from another normalizer which doesn't apply here. >- does it mean to assert something like newval->bv_val being no shorter than > val->bv_val see above. >- which would be "assert( (q - newval->bv_val) <= (p - val->bv_val) );", > right? That assertion *instead* of the two current assertions, right? The previous was likely intended to check two different things. >- shouldn't the code ensure that the ch_malloc() calls succeeded? That's a *big* TODO list item. Kurt
changed state Open to Closed
changed notes changed state Closed to Release moved from Incoming to Software Bugs
changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
fixed in HEAD and re20