Hello tech@. This one being discovered by Roman Kravchuk using Kannel port (see https://github.com/jasperla/openbsd-wip/tree/master/net/kannel).
While stress testing, Kannel components die with Program received signal SIGSEGV, Segmentation fault. [Switching to thread 1006387] 0x00000cb33345cf6e in random () at /usr/src/lib/libc/stdlib/random.c:387 387 *fptr += *rptr; We suspect threading issue because of the following trace: Thread 10 (thread 1003160): #0 0x00000cb33344135a in _thread_sys___thrsleep () at <stdin>:2 #1 0x00000cb3315fac2a in pthread_cond_wait (condp=0xcb32a79c4b0, mutexp=Variable "mutexp" is not available. ) at /usr/src/lib/librthread/rthread_sync.c:500 #2 0x00000cb129f836ba in gwlist_consume () from /usr/local/sbin/bearerbox #3 0x00000cb129f121f1 in boxc_sender () from /usr/local/sbin/bearerbox #4 0x00000cb129f828dd in new_thread () from /usr/local/sbin/bearerbox #5 0x00000cb3315f911e in _rthread_start (v=Variable "v" is not available. ) at /usr/src/lib/librthread/rthread.c:122 #6 0x00000cb333434f9b in __tfork_thread () at /usr/src/lib/libc/arch/amd64/sys/tfork_thread.S:75 Cannot access memory at address 0xcb32b27c000 0x00000cb33345cf6e 387 *fptr += *rptr; (fptr and rptr are somewhat global static). We took a brief look at relevant NetBSD code http://cvsweb.netbsd.org/bsdweb.cgi/src/common/lib/libc/stdlib/random.c?rev=1.3 In NetBSD, both random and srandom are just a wrappers calling real functions under a mutex. For instance: void srandom(unsigned long x) { mutex_lock(&random_mutex); srandom_unlocked((unsigned int) x); mutex_unlock(&random_mutex); } Is it normal to not have a mutex protected *random in OpenBSD? Alexey
