Hi Stefan, On Mon, 2019-11-04 at 22:16 +0100, Stefan Seyfried wrote: > Hi, > > test-mesh-crypto segfaults for me. > > abuild@strolchi:~/rpmbuild/BUILD/bluez-5.52> gdb unit/test-mesh-crypto > > [....] > > [8.6.2 Service Data using Node Identity] > ID Resolving Key = 84396c435ac48560b5965385253e210c > 84396c435ac48560b5965385253e210c => PASS > Hash Input = 00000000000034ae608fbbc1f2c61201 > 00000000000034ae608fbbc1f2c61201 => PASS > Hash = 00861765aefcc57b > 00861765aefcc57b => PASS > Mesh ID Beacon = 0100861765aefcc57b34ae608fbbc1f2c6 > 0100861765aefcc57b34ae608fbbc1f2c6 => PASS > This is very strange. The unit test looks like it has completed successfully (at least from what you copy- pasted). That test 8.6.2 is the final test, and it looks happy. Can you verify for me that all the other tests completed successfully? There is a *small* chance that you could be running on an old kernel: Kernels version 4.8 and before had a bug in the AEAD crypto code that made mesh code (including this unit test) inoperable... But this should show up *first* in one of the earlier tests within this unit test... so look for any FAIL designations. The other thing about this particular test is that it is the *only* bluez unit test which is based on ELL (Embedded Linux Library) instead of GLIB. Are you running from an installed ELL when compiling bluez, or do you have ELL in a "peer directory"... For instance: .../work/ell .../work/bluez If you have the ELL source code available, please try running: ell % make check paying particular attention to the output of: unit/test-cipher If unit/test-cipher in ELL passes, then unit/test-mesh-crypto in BLUEZ should pass. > > Program received signal SIGSEGV, Segmentation fault. > 0x00007ffff7e874ae in mem2chunk_check () from /lib64/libc.so.6 > (gdb) bt > #0 0x00007ffff7e874ae in mem2chunk_check () from /lib64/libc.so.6 > #1 0x00007ffff7e8b6af in free_check () from /lib64/libc.so.6 > #2 0x0000555555557c98 in l_free (ptr=<optimized out>) at ell/util.c:136 > #3 l_queue_clear (queue=0x55555556d010, destroy=0x555555557c60 > <l_free>) at ell/queue.c:107 > #4 0x0000555555557210 in _sub_D_65535_1.7021 () at ell/cipher.c:319 > #5 0x00007ffff7fe2c13 in _dl_fini () from /lib64/ld-linux-x86-64.so.2 > #6 0x00007ffff7e3f877 in __run_exit_handlers () from /lib64/libc.so.6 > #7 0x00007ffff7e3fa2c in exit () from /lib64/libc.so.6 > #8 0x00007ffff7e27e12 in __libc_start_main () from /lib64/libc.so.6 > #9 0x0000555555557b8a in _start () at ../sysdeps/x86_64/start.S:120 > > this is reproducible here, I'm disabling this test for now in the > openSUSE package build. > > Best regards
