Bug 573896 - initializing subtree with invalid syntax crashes ns-slapd
Summary: initializing subtree with invalid syntax crashes ns-slapd
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Database - Import/Export
Version: 1.2.5
Hardware: i686
OS: Linux
low
medium
Target Milestone: ---
Assignee: Noriko Hosoi
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434914 389_1.2.6
TreeView+ depends on / blocked
 
Reported: 2010-03-16 03:02 UTC by Christopher Wood
Modified: 2015-12-07 17:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:16:30 UTC


Attachments (Terms of Use)
error log from the import session (16.19 KB, application/octet-stream)
2010-03-16 03:07 UTC, Christopher Wood
no flags Details
valgrind output while it crashed (83.80 KB, application/octet-stream)
2010-03-16 03:08 UTC, Christopher Wood
no flags Details
gdb where output after an earlier crash (1.38 KB, application/octet-stream)
2010-03-16 03:10 UTC, Christopher Wood
no flags Details
git patch file (4.15 KB, patch)
2010-03-16 23:51 UTC, Noriko Hosoi
nkinder: review+
Details | Diff
test data (example1k.ldif) (1.43 MB, text/plain)
2010-03-17 19:38 UTC, Noriko Hosoi
no flags Details

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


Note You need to log in before you can comment on or make changes to this bug.