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.
Created attachment 400361 [details] error log from the import session
Created attachment 400362 [details] valgrind output while it crashed
Created attachment 400363 [details] gdb where output after an earlier crash
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.
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
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.
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.
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