Re: (ITS#3407) run ldapdelete with log output, slapd core dumped

[zhang@fjh.fujitsu.com]

Hello

> I have no idea of what "default stable *.sql definition" means; can you
> answer my question? 
"default stable *.sql definition" meant that I had used all *.sql definition 
files stored in openldap-2.2.xx/servers/slapd/back-sql/rdbms_depend/pgsql 
* Almost I hadn't extended them.

> Is there any definition in the "ldap_attr_mappings" table you're using 
> with an empty (i.e. NULL) "delete_rule" field? 
In the default testdb_metadata.sql, almost for each "delete_proc", "NULL" 
had been set as a value. See the following.
---------
insert into ldap_attr_mappings (id,oc_map_id,name,sel_expr,from_tbls,join_where,add_proc,delete_
proc,param_order,expect_return) values (4,1,'sn','persons.surname','persons',NULL,'update person
s set surname=? where id=?',NULL,3,0);
---------

On Solaris, if run ldapdete with SLAPD log outputing, SLAPD core dumped. 
This isn't related to version. I tested it with 2.2.19, core_dump occurred 
too.

About the reason, just like what you said:
> the problem should be related with your system's vsnprintf() that doesn't 
> like NULL string values (because it applies strlen() without checking. 

For proving your supposition is correct, checked core file by xcrash again:
----------------
# /opt/xcrash/scrash core /usr/local/libexec/slapd
scrash 2.493 for FUJITSU PRIMEPOWER/GP7000F/GP-S
Copyright (c) FUJITSU LIMITED 1998-2002 All Right Reserved.
##### elfinfo ver 7.1-2.484 #####               type "help" for help.

Warning: /usr/local/libexec/slapd is newer than core.

Multi thread process. This core has 3 lwps.

signal : SIGSEGV        fault pc: 0xff0b347c     libc.so.1:strlen+0x80
platform: SUNW,Sun-Blade-100
(scrash) ana
...
[ 1] libc.so.1:strlen+0x80     ld      [%o1], %o2
 [%sp] fe3fda68
 [%l0]0x000c6c36  [%l1]0x00000000  [%l2]0x00000000  [%l3]0x000c6c37
 [%l4]0x00000000  [%l5]0x00000800  [%l6]0x000e40e9  [%l7]0x00000000
 [%i0]0x000c6bf8  [%i1]0x00000000  [%i2]0xfe3fe770  [%i3]0x00000000
 [%i4]0x00000000  [%i5]0x000f56b0  [%i6]0xfe3fe710  [%i7]0xff1079c4
[ 2] libc.so.1:vsnprintf+0x5c  call    _doprnt (ff13e19c)
 [%sp] fe3fe710
 [%l0]0x7fffffff  [%l1]0x00000000  [%l2]0x00001c00  [%l3]0x0000001e
 [%l4]0x00000000  [%l5]0xfe3ff7c0  [%l6]0x00001c00  [%l7]0xff39d198
 [%i0]0xfe3fe7e0  [%i1]0x00001000  [%i2]0x000c6bf8  [%i3]0xfe3ff840
 [%i4]0x0000004c  [%i5]0x00000053  [%i6]0xfe3fe780  [%i7]0x000a90ac
...
(scrash) dump 0xfe3fe7e0
fe3fe7e0 : 20202062 61636b73 716c5f6d 6f646966       backsql_modif
fe3fe7f0 : 795f6465 6c657465 5f616c6c 5f76616c    y_delete_all_val
fe3fe800 : 75657328 293a2065 72726f72 20707265    ues(): error pre
fe3fe810 : 70617269 6e672071 75657279 20000000    paring query ...
fe3fe820 : 00277fec 00001130 00000300 00000000    .'.....0........
fe3fe830 : ff1415a0 ff13fc81 00000000 fe3fe94c    .............?.L
fe3fe840 : fed8a888 fe3ff98c 00000000 00000000    .....?..........
fe3fe850 : fffffffd fffffffd fffffffd ff39d198    .............9..
(scrash) dump 0x00001000
(scrash) dump 0x000c6bf8
c6bf8 : 6725643d 256c750a 00000000 00000000    g%d=%lu.........
c6c08 : 20202062 61636b73 716c5f6d 6f646966       backsql_modif
c6c18 : 795f6465 6c657465 5f616c6c 5f76616c    y_delete_all_val
c6c28 : 75657328 293a2065 72726f72 20707265    ues(): error pre
c6c38 : 70617269 6e672071 75657279 2025730a    paring query %s.
c6c48 : 00000000 00000000 286e756c 6c290000    ........(null)..
c6c58 : 61646400 00000000 64656c65 74650000    add.....delete..
c6c68 : 7265706c 61636500 696e6372 656d656e    replace.incremen
(scrash) dump 0xfe3ff840
fe3ff840 : 00000000 00000000 00000000 00000000    ................
fe3ff850 : fe3ffb84 00000000 00000000 00000001    .?..............
fe3ff860 : feda1c34 00000001 0028af88 00134400    ...4.....(....D.
fe3ff870 : 00011c00 00131bd8 000f6e48 0026dfa0    ..........nH.&..
fe3ff880 : 000f6da8 ff39d198 00134400 00000001    ..m..9....D.....
fe3ff890 : 00000000 00000001 00000000 ff040400    ................
fe3ff8a0 : 00000000 00000000 00000000 00000000    ................
fe3ff8b0 : 00000000 00000000 001502c8 fe3ffab8    .............?..

See "fe3ff840 : 00000000 00000000 00000000 00000000    ................", 
it told us vsnprintf() had sth wrong. 

By modified /back-sql/add.c, SLAPD goes well.
line 135 	Debug( LDAP_DEBUG_TRACE,
line 136		"   backsql_modify_delete_all_values(): "
line 137		"error preparing query %s\n",
line 138		((at->bam_delete_proc)==NULL)?"(null)":at->bam_delete_proc, 0, 0 );

Is your environment Windows or Linux? On Solaris, this problem must occur.

regards