On Thursday, September 27, 2012, Alexey Suslikov wrote: > 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? >
Philip, can you help us to write threaded test case (spawning a number of threads each calling random)?
