Ok, this is just at the memcopy above.
I see in this trace that the AC_MEMCPY got mapped to __memmove_ssse3 of 

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 expect that the compile time detection switched to memmove and the runtime 
feature detection found sse3 and used that.
We could do two things to try here:
1. we could modify your guest to not expose sse3 and retest in there (-cpu 
qemu64/qemu32 will be without sse3 and without a lot other special HW features 
- if you run with -cpu host you can do "-enable-kvm -cpu host,-sse3" to just 
kill this feature). How do you start your KVM guest (commandline, libvirt, 
other - so we know how to help you modify?
2. we could try to influence the build to not use memmove but memcpy or bcopy 
instead and check if that makes it work.

You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.

  Spurious SEGV running inside kvm

Status in openldap package in Ubuntu:
Status in qemu package in Ubuntu:

Bug description:
  Running a continuous stream of operations against OpenLDAP slapd
  eventually causes a SEGV in liblber, in a segment of code that cannot

   gdb /opt/symas/lib64/slapd CoreDump 
  GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
  Copyright (C) 2016 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 "x86_64-linux-gnu".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  Find the GDB manual and other documentation resources online at:
  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from /opt/symas/lib64/slapd...done.
  [New LWP 5472]
  [New LWP 5468]
  [New LWP 5524]
  [New LWP 5471]
  [New LWP 5469]
  [New LWP 5507]
  [New LWP 5510]
  [New LWP 5470]
  [New LWP 5506]
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  Core was generated by `/opt/symas/lib64/slapd -u root -g root -h ldap:///'.
  Program terminated with signal SIGSEGV, Segmentation fault.
  #0  0x00007f4e2c9f0160 in ber_dupbv_x (dst=0x196b268, src=0x7f25f8001070, 
ctx=0x0) at /home/build/git/sold-master/openldap/libraries/liblber/memory.c:513
  513             new->bv_val[src->bv_len] = '\0';
  [Current thread is 1 (Thread 0x7f260e242700 (LWP 5472))]
  (gdb) l 500
  495                     if(( new = ber_memalloc_x( sizeof(struct berval), ctx 
)) == NULL ) {
  496                             return NULL;
  497                     }
  498             }
  500             if ( src->bv_val == NULL ) {
  501                     new->bv_val = NULL;
  502                     new->bv_len = 0;
  503                     return new;
  504             }
  506             if(( new->bv_val = ber_memalloc_x( src->bv_len + 1, ctx )) == 
NULL ) {
  507                     if ( !dst )
  508                             ber_memfree_x( new, ctx );
  509                     return NULL;
  510             }
  512             AC_MEMCPY( new->bv_val, src->bv_val, src->bv_len );
  513             new->bv_val[src->bv_len] = '\0';
  514             new->bv_len = src->bv_len;
  (gdb) p *new
  $1 = {bv_len = 0, bv_val = 0x0}
  (gdb) p *src
  $2 = {bv_len = 36, bv_val = 0x7f268ccc7bee <error: Cannot access memory at 
address 0x7f268ccc7bee>}

  At line 506 we allocate some memory and check for a failure (returning NULL) 
and leave the function at line 509 if there was a failure. The allocation is 
for 37 bytes of memory and a memcpy into that memory succeeds on line 512. The 
SEGV occurs at line 513 and the pointer that was just returned from the 
allocator is NULL at this point. There are no other active threads that could 
be stomping on memory, there's no stack overrun or any other misbehavior that 
can account for it. Also, the identical test sequence completes without 
incident when running on the host OS instead of under kvm.
  (The src->bv_val pointer points to valid data at the time of the crash; it's 
just residing in a mmap'd file and that mapping isn't preserved in the 
coredump. So ignore gdb's error there.)

  Something in kvm is writing zeroes over a field of memory after we
  already checked that it was non-zero.

  This is on 
  Linux anvil1 4.4.0-112-generic #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  Both the host and the guest VM are on identical OS revision.

To manage notifications about this bug go to:

Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to