[Expired for openldap (Ubuntu) because there has been no activity for 60
days.]
** Changed in: openldap (Ubuntu)
Status: Incomplete => Expired
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
** Changed in: openldap (Ubuntu)
Status: In Progress => Incomplete
** Changed in: openldap (Ubuntu)
Assignee: Howard Chu (hyc) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
Hi Howard, I assigned this to you since you marked it as 'in progress'
(as is convention). If that is not correct, you can unassign yourself
and set it back to 'triaged' or 'confirmed' to allow someone else to
pick it up.
Thanks!
** Changed in: openldap (Ubuntu)
Assignee: (unassigned) =>
I think we can close this out, we were able to reproduce the issue
without kvm. Sorry for the false alarm.
** Changed in: qemu (Ubuntu)
Status: Incomplete => Invalid
** Changed in: openldap (Ubuntu)
Status: Confirmed => Invalid
** Changed in: openldap (Ubuntu)
Status:
I suggest that the problem does not reproduce on https://github.com/leo-
yuriev/ReOpenLDAP.
Please provide a testcase, I will check.
Under kvm gettimeofday() is costly, so I suggest this just expose one of
race condition in the slapd.
LDAP_JITTER maybe usefull to reproduce bug without kvm.
Ok, this is just at the memcopy above.
I see in this trace that the AC_MEMCPY got mapped to __memmove_ssse3 of
../sysdeps/x86_64/multiarch/memcpy-ssse3.S
Lets assume (for the sake of trying something until you have a simplified
reproducer) that sse3 might be broken in KVM on your system.
I'd
It can also die with the following backtrace:
(gdb) bt
#0 __memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2331
#1 0x7f570da4a14e in ber_dupbv_x (dst=0x25f55e8, src=0x7f2ee8001200,
ctx=0x0) at
/home/build/git/sold-2445/openldap/libraries/liblber/memory.c:512
#2
Will try to come up with a minimal reproducer. Currently it takes
several hours to run the complete test, and a few hours before the SEGV
occurs. But the stack trace is always identical when it happens. In
multiple runs, it always succeeds on the host and always fails in the
VM.
--
You received
Eventually as you already found the question is how did bv_val get 0x0?
If the test can't be passed to me, but is reproducible, could you try to step
live from line 506.
1. is new->bv_val really assigned some pointer (and which one)
2. when does that pointer get lost between 506 and 513
Also
How reproducible is this - everytime or just once in a number of retry loops?
Could you share the minimal simplified setup+loop code to retrigger this over
here?
** Changed in: qemu (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of
Setting qemu(Ubuntu) which is the right package for the question of "the
identical test sequence completes without incident when running on the
host OS instead of under kvm".
Although that could just be timing and doesn't "have to be" a kvm memory
clobbering.
--
You received this bug
slapd is part of the openldap package - assigning this makes more sense
I think.
** Package changed: kvm (Ubuntu) => openldap (Ubuntu)
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Touch
12 matches
Mail list logo
