Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 573896

Summary: initializing subtree with invalid syntax crashes ns-slapd
Product: [Retired] 389 Reporter: Christopher Wood <unregenerate>
Component: Database - Import/ExportAssignee: Noriko Hosoi <nhosoi>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: low    
Version: 1.2.5CC: andrey.ivanov, jgalipea, rmeggins, unregenerate
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 17:16:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 434914, 543590    
Attachments:
Description Flags
error log from the import session
none
valgrind output while it crashed
none
gdb where output after an earlier crash
none
git patch file
nkinder: review+
test data (example1k.ldif) none

Description Christopher Wood 2010-03-16 03:02:38 UTC 
Description of problem:

I have a db2ldif dump.ldif from Netscape Directory Server 6.2 (which per Rich Megginson "had no syntax-based data validation whatsoever"), with invalid syntax in a number of its entries. Using this to initialize a subtree under 389 DS 1.25 crashes ns-slapd. 

Version-Release number of selected component (if applicable):

ns-slapd 1.2.5

How reproducible:

Most of the time. Sometimes, for reasons that escape me, the import completes (but without all the invalid data), yet ns-slapd doesn't crash.

Steps to Reproduce:

1. In the admin gui, choose "initialize database" in a subtree.
2. Select my dump.ldif, begin the initialization.
3. Wait.
  
Actual results:

ns-slapd crashes

Expected results:

ns-slapd stays running and has a newly initialized subtree with dump.ldif's valid data.

Additional info:

The email thread where I asked about my crash:

http://lists.fedoraproject.org/pipermail/389-users/2010-March/011164.html

I will attach other bits after I submit this.

I'm filing this as a medium severity because while it does crash ns-slapd, this is while trying to initialize a database with a fairly dirty data source.
Comment 1 Christopher Wood 2010-03-16 03:07:06 UTC 
Created attachment 400361 [details]
error log from the import session
Comment 2 Christopher Wood 2010-03-16 03:08:55 UTC 
Created attachment 400362 [details]
valgrind output while it crashed
Comment 3 Christopher Wood 2010-03-16 03:10:46 UTC 
Created attachment 400363 [details]
gdb where output after an earlier crash
Comment 4 Noriko Hosoi 2010-03-16 23:51:41 UTC 
Created attachment 400601 [details]
git patch file

Files:
 ldap/servers/slapd/slap.h
 ldap/servers/slapd/task.c

Description: When an import is executed using a task mechanism,
slapi_task_log_notice is called for logging, where task_log field
points the memory storing the log messages.  If multiple log
messages were logged by multiple worker threads simultaneously,
there was a chance that the address of the log message was switched
by realloc while the other threads were accessing the old address.
This patch introduces task_log_lock per task to protect task_log.
Note: slapi_ch_malloc and its friends never return NULL. They rather
exits.  Thus, to avoid the confusion which may look leaking the
lock, I eliminated 2 error returns from slapi_task_log_notice.
Comment 5 Noriko Hosoi 2010-03-17 17:03:54 UTC 
Reviewed by Nathan (Thank you!!!)

Pushed to master.

$ git merge fix
Updating 23bf606..0cd1fc4
Fast forward
 ldap/servers/slapd/slap.h |    2 ++
 ldap/servers/slapd/task.c |   21 +++++++++++++++++----
 2 files changed, 19 insertions(+), 4 deletions(-)
[nhosoi@kiki ldapserver 2692]$ git push
Counting objects: 13, done.
Delta compression using 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.27 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   23bf606..0cd1fc4  master -> master

Pushed to Directory_Server_8_2_Branch.

$ git push origin ds82-local:Directory_Server_8_2_Branch
Counting objects: 13, done.
Delta compression using 4 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 1.28 KiB, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   81de991..f4cce0c  ds82-local -> Directory_Server_8_2_Branch
Comment 6 Noriko Hosoi 2010-03-17 19:38:47 UTC 
Created attachment 400868 [details]
test data (example1k.ldif)

How to verify:
1. prepare a server (suffix: dc=example,dc=com, backend: userRoot)
2. start the server
3. /path/to/ldif2db.pl -D "cn=directory manager" -w <pw> -n userRoot -i /path/to/example1k.ldif

Run 'ps -ef | grep ns-slapd' to check if the server is alive or not.  If the ns-slapd process is found, it's verified this bug is fixed.
Comment 7 Christopher Wood 2010-03-22 22:33:36 UTC 
I have been unable to reproduce this crash using Noriko Hosoi's patch. I imported both his example1k.ldif and my Netscape Directory Server 6.2 dump.ldif without a slapd crash.

This is with 389 DS 1.2.6a2+patch.
Comment 8 Jenny Severance 2010-06-04 19:27:52 UTC 
verified - RHEL 4

version:
redhat-ds-base-8.2.0-2010060404.el4dsrv


#./ldif2db.pl -D "cn=Directory Manager" -w Secret123 -n userRoot -i /home/jgalipea/example1k.ldif 
adding new entry cn=import_2010_6_4_15_26_4, cn=import, cn=tasks, cn=config
# ps -ef | grep slapd
nobody   31730     1  2 15:22 ?        00:00:06 ./ns-slapd -D /etc/dirsrv/slapd-jgalipea-rhel4 -i /var/run/dirsrv/slapd-jgalipea-rhel4.pid -w /var/run/dirsrv/slapd-jgalipea-rhel4.startpid
root     31953 30684  0 15:26 pts/4    00:00:00 grep slapd