[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) (71.241.153.69)
>
>
>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.
>modifications:
> 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
><==backsql_get_attr_vals()
>
>
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.
>Aborted
>== 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.
p.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497