#47734 Change made in resolving ticket #346 fails on Debian SPARC64
Closed: wontfix Opened by morgangreywolf.

When running setup-ds-admin, the script fails during directory server creation:

[root@ldapsrv01 ~]# setup-ds-admin
 [---snip---]
Are you ready to set up your servers? [yes]:
Creating directory server . . .
Could not import LDIF file '/tmp/ldif2msatd.ldif'.  Error: 35328.  Output: importing data ...
Bus error
Error: Could not create directory server instance 'ldapsrv01'.
Exiting . . .
Log file is '/tmp/setup4EkQUt.log'

Tracing through the script, I determined that the bus error is coming when script calls 'ns-slapd -D /etc/dirsrv/slapd-$(hostname) -i /tmp/ldifXXXXXX.ldif'

Running this in gdb results in:

[root@ldapsrv01 ~]# gdb /usr/sbin/ns-slapd
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "sparc-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/ns-slapd...(no debugging symbols found)...done.
(gdb) run ldif2db -D /etc/dirsrv/slapd-ldapsrv01 -i /tmp/ldifs9EhyD.ldif
Starting program: /usr/sbin/ns-slapd ldif2db -D /etc/dirsrv/slapd-ldapsrv01 -i /tmp/ldifs9EhyD.ldif
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc-linux-gnu/libthread_db.so.1".
Program received signal SIGBUS, Bus error.
slapi_has8thBit (s=0xffff92e6 "extensibleobject")
    at ../ldap/servers/slapd/utf8compare.c:72
72              if (MY8THBITFILTER & *uip) {
(gdb)

Which, as you can see, is in the slapi_has8thBit() function in ldap/servers/slapd/utf8compare.c

After backing out the patch generated from Trac ticket #346, ldif2db and, of course, the setup-ds-admin script both work as expected.

I'm running on Debian Wheezy sparc64 and building with gcc 4.6.3 and I'm compiling against libnspr4 version 4.9.2-1+deb7u1, straight from the wheezy repos.

I've confirmed that the slapi_has8thBit() function is identical in the current master branch in git, BTW, so this bug really applies to all versions of 389 since 1.2.11.


Makes ns-slapd 1.3.0.3 and later work on Debian Sparc64
fix_slapi_has8thBit.patch

Actually, I only backed out the portion of the patch that affects ldap/servers/slapd/utf8compare.c, not the whole thing. I'm attaching the patch I applied to make 389 work on Debian Sparc64

I see. We could back off the patch. Thanks.

Description: The following change is not generic beyond x86 and x86_64 architecture.
{{{
commit c0151f78509c35250095da6e2785842337963008
Trac Ticket #346 - Slow ldapmodify operation time for large
quantities of multi-valued attribute values
3) In slapi_has8thBit, instead of checking the 8th bit one byte
by one byte, check 4 bytes at one time.
}}}
Putting the change into:
{{{

if (defined(CPU_x86) || defined(CPU_x86_64))

}}}

Reviewed by Rich (Thank you!!)

Pushed to master:
2ec0cdb..1e00913 master -> master
commit 1e00913312e165ead2f3a25b6d70f7839115007e

Pushed to 389-ds-base-1.3.2:
dee6ed1..ba9248d 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit ba9248d02447dc693114961d9296ecb742a75add

Pushed to 389-ds-base-1.3.1:
a433ed7..450607a 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 450607a75d23984da12c83e785a2e1cfbf49964d

Pushed to 389-ds-base-1.2.11:
1361c27..9760c04 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 9760c042717fdaba5af65999629ff87fde46520d

Metadata Update from @morgangreywolf:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.2.11.26

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1067

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

Metadata