It can also die with the following backtrace: (gdb) bt #0 __memmove_ssse3 () at ../sysdeps/x86_64/multiarch/memcpy-ssse3.S:2331 #1 0x00007f570da4a14e in ber_dupbv_x (dst=0x25f55e8, src=0x7f2ee8001200, ctx=0x0) at /home/build/git/sold-2445/openldap/libraries/liblber/memory.c:512 #2 0x00007f570da4a19f in ber_dupbv (dst=0x25f55e8, src=0x7f2ee8001200) at /home/build/git/sold-2445/openldap/libraries/liblber/memory.c:523 #3 0x00007f57091a07b4 in accesslog_op_mod (op=0x7f2f0518e780, rs=0x7f2f0518e030) at /home/build/git/sold-2445/openldap/servers/slapd/overlays/accesslog.c:2031 #4 0x00000000004d9be5 in overlay_op_walk (op=0x7f2f0518e780, rs=0x7f2f0518e030, which=op_modify, oi=0x25eb720, on=0x25f53c0) at /home/build/git/sold-2445/openldap/servers/slapd/backover.c:661 #5 0x00000000004d9ee1 in over_op_func (op=0x7f2f0518e780, rs=0x7f2f0518e030, which=op_modify) at /home/build/git/sold-2445/openldap/servers/slapd/backover.c:730 #6 0x00000000004da044 in over_op_modify (op=0x7f2f0518e780, rs=0x7f2f0518e030) at /home/build/git/sold-2445/openldap/servers/slapd/backover.c:769 #7 0x00000000004cc061 in syncrepl_updateCookie (si=0x26499f0, op=0x7f2f0518e780, syncCookie=0x7f2f0518e290) at /home/build/git/sold-2445/openldap/servers/slapd/syncrepl.c:3982 #8 0x00000000004c0bd5 in do_syncrep2 (op=0x7f2f0518e780, si=0x26499f0) at /home/build/git/sold-2445/openldap/servers/slapd/syncrepl.c:1019 #9 0x00000000004c2ea6 in do_syncrepl (ctx=0x7f2f0518ec30, arg=0x25ebb40) at /home/build/git/sold-2445/openldap/servers/slapd/syncrepl.c:1567 #10 0x000000000043dbed in connection_read_thread (ctx=0x7f2f0518ec30, argv=0x11) at /home/build/git/sold-2445/openldap/servers/slapd/connection.c:1296 #11 0x00007f570dc6a909 in ldap_int_thread_pool_wrapper (xpool=0x24e8500) at /home/build/git/sold-2445/openldap/libraries/libldap_r/tpool.c:963 #12 0x00007f570d8276ba in start_thread (arg=0x7f2f0518f700) at pthread_create.c:333 #13 0x00007f570c86f41d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
On Wed, Feb 14, 2018 at 6:45 AM, Howard Chu <h...@symas.com> wrote: > 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 this bug notification because you are subscribed to the bug > report. > https://bugs.launchpad.net/bugs/1749247 > > Title: > Spurious SEGV running inside kvm > > To manage notifications about this bug go to: > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/ > 1749247/+subscriptions > -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1749247 Title: Spurious SEGV running inside kvm Status in openldap package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Incomplete Bug description: Running a continuous stream of operations against OpenLDAP slapd eventually causes a SEGV in liblber, in a segment of code that cannot fail: 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: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. 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 } 499 500 if ( src->bv_val == NULL ) { 501 new->bv_val = NULL; 502 new->bv_len = 0; 503 return new; 504 } (gdb) 505 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 } 511 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>} (gdb) 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: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1749247/+subscriptions -- 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