On Thursday, September 27, 2012, Philip Guenther wrote: > On Thu, 27 Sep 2012, Alexey Suslikov wrote: > > Removing only local variables part reverts us to previous behavior (i.e. > > crashes). > > My guess is your program is calling srandom(), srandomdev(), initstate() > or setstate() as well. Your diff doesn't protect the alteration of state, > end_ptr, fptr, and rptr on those paths, so a call to initstate() while > another thread is in random() can walk fptr and/or rptr out of the state > array. Add the necessary locking in them and run your tests again. > > If not, well, crank up your debugging skills. What was the line of code > that actually triggered the crash? Where did the bogus pointer come from? > > Crash:
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; Back 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; > > > I'm starting to believe that static globals are not good. > > They are incredibly good at what they do. If you're trying to say that > they fundamentally can't be thread-safe, you'll need some extraordinary > evidence for such a claim. > > What good they do? Cheers, Alexey
