[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: (ITS#3861) Crash when trying to change password (with BACK-SQL)

pelder@gmail.com wrote:

>Full_Name: Preston A. Elder
>Version: 2.3.4
>OS: Linux (2.6.12)
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (
>I'm trying to change my user's password via. a web script, openldap keeps
>aborting, in the same place.
>The user is valid.  I will paste 2 VERY verbose dumps.  The first is of the app
>requesting information about my user (uid=prez).  As you can see, it succeeds,
>and returns the info.  The second is of the actual attempt to modify the
>password.  This causes the assertion to trigger.
The error occurs in a very generic place, with very little significant 
indications of failure.  It appears that the passwrod chage succeeded, 
but the resulting dynamically generated entry is corrupted. 

>        replace: userpassword
>                one value, length 33
Is the column of the table containing the userPassword large enough to 
hold this value?

>==>backsql_modify_internal(): traversing modifications list
>   backsql_modify_internal(): modifying attribute "userPassword" (replace)
>according to mappings for objectClass "gnUser"
>   backsql_modify_internal(): replacing values for attribute "userPassword"
>   backsql_modify_internal(): delete procedure is not defined for attribute
>"userPassword" - adding only
>   backsql_modify_internal(): adding new values for attribute "userPassword"
>   backsql_modify_internal(): arg2="7"
>   backsql_modify_internal(): arg1="{SHA}GCf1rKqqIm82tZmejy2RQX6zihM=";
>executing "select set_gnUser_userPassword(?,?)"
><==backsql_modify_internal(): 0
Apparently, the modification succeeded.

>==>backsql_get_attr_vals(): oc="gnUser" attr="userPassword" keyval=7
>backsql_get_attr_vals(): number of values in query: 1
Apparently, the modified value of userPassword was correctly retrieved

>slapd: schema_check.c:83: entry_schema_check: Assertion `a->a_vals[0].bv_val !=
>((void *)0)' failed.
>== END DUMP 2 =================================================
It may be that back-sql is for some reason letting an attribute with no 
values slip thru.  You should intercept that assertion by running a 
non-stripped version of slapd under gdb and letting it fail.  Then, 
print the value of a->a_desc->ad_cname and any other useful information 
that can be found about that attribute (e.g. the schema of the table 
that's containing it, the row in ldap_attr_mappings that's taking care 
of its handling (including the stored procedures that are called, if 
any).  Info about the RDBMS may be of help.


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497