On Mon, Jan 2, 2017 at 11:17 AM, Christophe Milard <christophe.mil...@linaro.org> wrote: > Hi > > I have noticed that (rarely enough to be a pain to catch) odp_shm and > odpdrv_shm sress test sigfaults. > I saw it once last week, but that was enough to worry me as the common > part between the two tests is really the new memory allocator, _ishm. > So I ran a test over new year trying to catch the problem -or at least > one of then :-) - and I did caught some fish: > > Segfault can of course be due to very different bug, but still the > location of the segfault may tell something: > Here follows the baktrace: > Thread 14 "drvshmem_main" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffc3f2a700 (LWP 40073)] > 0x00007ffff73e59f8 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > (gdb) bt > #0 0x00007ffff73e59f8 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #1 0xca62c1d6ca62c1d6 in ?? () > #2 0xca62c1d6ca62c1d6 in ?? () > #3 0xca62c1d6ca62c1d6 in ?? () > #4 0xca62c1d6ca62c1d6 in ?? () > #5 0xca62c1d6ca62c1d6 in ?? () > #6 0xca62c1d6ca62c1d6 in ?? () > #7 0xca62c1d6ca62c1d6 in ?? () > #8 0xca62c1d6ca62c1d6 in ?? () > #9 0x00000000000003e8 in ?? () > #10 0x0000000000000068 in ?? () > #11 0x00007ffff754a6b0 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #12 0x00007ffff73dae78 in CRYPTO_malloc () from > /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #13 0x00007ffff73e29c8 in SHA1_Update () from > /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #14 0x00007ffff74931c0 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #15 0x00007ffff74935b5 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > #16 0x000000000040d038 in odp_random_data (buf=0x7fffc3f17ba3 "", > len=5, kind=ODP_RANDOM_BASIC) at odp_crypto.c:1015 > #17 0x0000000000407367 in run_test_stress (arg=0x7fffffffdc58) at > drvshmem.c:599 > #18 0x000000000040a6ae in odpthread_run_start_routine (arg=0x665890 > <thread_tbl>) at linux.c:275 > #19 0x00007ffff6d146ba in start_thread (arg=0x7fffc3f2a700) at > pthread_create.c:333 > #20 0x00007ffff6a4a82d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 > > That triggered the following question: > The ODP threads used to stress the memory allocator during the test > use odp_random_data() to generate random allocation sizes (and a few > other random things). My assumption was that being an ODP basic block > it would be odpthread safe (right now odp_thread = pthread). Is it? > https://wiki.openssl.org/index.php/Libcrypto_API#Thread_Safety says > "OpenSSL currently is thread-NOT-safe by default"... > > Are we hitting this limitation here?
It would appear so. Some research shows that OpenSSL is by default not thread-safe. Please open a bug for this so it can be properly investigated. I'm not sure if this may affect the various ODP crypto routines as well since by default odp-linux is using OpenSSL. > > Christophe.
