Re: test-mesh-crypto segfaults

["Gix, Brian" <brian.gix@intel.com>]

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