Issue 1254 - core dump in numericStringNormalize()
Summary: core dump in numericStringNormalize()
Status: VERIFIED FIXED
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-07-24 16:14 UTC by Peter W
Modified: 2014-08-01 21:06 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description Peter W 2001-07-24 16:14:43 UTC
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


Comment 1 Peter W 2001-07-24 17:37:07 UTC
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
Comment 2 Kurt Zeilenga 2001-07-24 17:47:32 UTC
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

Comment 3 Kurt Zeilenga 2001-07-28 16:26:34 UTC
changed state Open to Closed
Comment 4 Kurt Zeilenga 2001-08-02 16:17:22 UTC
changed notes
changed state Closed to Release
moved from Incoming to Software Bugs
Comment 5 Kurt Zeilenga 2001-08-30 23:45:35 UTC
changed state Release to Closed
Comment 6 Kurt Zeilenga 2002-06-19 01:39:18 UTC
moved from Software Bugs to Archive.Software Bugs
Comment 7 OpenLDAP project 2014-08-01 21:06:56 UTC
fixed in HEAD and re20