#47734 Change made in resolving ticket #346 fails on Debian SPARC64
Closed: wontfix None Opened 10 years ago 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 c0151f7
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 1e00913

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

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

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

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

7 years ago

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)

3 years ago

Login to comment on this ticket.

Metadata