Bug#866122: slapd-mtread crash on ppc64{,el} in stretch/sid
Control: found -1 4.9.88-1+deb9u1
Hi,
On Sun, Jul 01, 2018 at 03:42:12AM +0100, Ben Hutchings wrote:
Is this bug still present?
It still reproduces with the current stretch kernel:
debian@debian:~/openldap-2.4.44+dfsg/debian/build/tests$ ./run -b mdb test060-mt-hot
Cleaning up test run directory leftover from previous run.
Running ../../../tests/scripts/test060-mt-hot for mdb...
running defines.sh
Running slapadd to build slapd database...
Running slapindex to index slapd database...
Starting slapd on TCP/IP port 9011...
/home/debian/openldap-2.4.44+dfsg/debian/build/tests/../servers/slapd/slapd -s0 -f /home/debian/openldap-2.4.44+dfsg/debian/build/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d stats
Testing basic monitor search...
Monitor searches
Testing basic mt-hot search: 1 threads (1 x 50000) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 1 -L 1 -l 50000
Testing basic mt-hot search: 5 threads (1 x 10000) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 5 -L 1 -l 10000
Testing basic mt-hot search: 100 threads (5 x 100) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e cn=Monitor -m 100 -L 5 -l 100
Random searches
Testing random mt-hot search: 1 threads (1 x 50000) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e dc=example,dc=com -f (objectclass=*) -m 1 -L 1 -l 50000
Testing random mt-hot search: 5 threads (1 x 10000) loops...
./progs/slapd-mtread -H ldap://localhost:9011/ -D cn=Manager,dc=example,dc=com -w secret -e dc=example,dc=com -f (objectclass=*) -m 5 -L 1 -l 10000
slapd-mtread failed (139)!
debian@debian:~/openldap-2.4.44+dfsg/debian/build/tests$ uname -a
Linux debian 4.9.0-6-powerpc64le #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) ppc64le GNU/Linux
However it looks like it might be resolved with the kernel in unstable.
I will run some more iterations and let you know.
a7771176 (4.15) looks interesting - it's specifically tagged as fixing
the commit I isolated as the broken one (dc16b553), and the message
sounds relevant. If the unstable kernel survives multiple runs I'll see
what this does on 4.9.
https://patchwork.ozlabs.org/patch/833190/
Reply to: