Also, make sure your ELL version is at least Release 0.26, from 30-Oct-2019. On Mon, 2019-11-04 at 22:11 +0000, Gix, Brian wrote: > 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
