Bug 2798 Christophe
On 2 January 2017 at 22:02, Bill Fischofer <[email protected]> wrote: > On Mon, Jan 2, 2017 at 11:17 AM, Christophe Milard > <[email protected]> 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.
