deadlock in fork call?

[Stephen Bartnikowski]

Thanks Alfred. I mostly do programming, so I didn't even think to put my
admin hat on. Sounds like this patch will do the job.

- Stephen 

> -----Original Message-----
> From: Alfred Perlstein [mailto:alfred at freebsd.org] 
> Sent: Tuesday, October 28, 2008 11:40 AM
> To: Stephen Bartnikowski
> Cc: freebsd-threads at freebsd.org
> Subject: Re: deadlock in fork call?
> 
> I'm pretty sure this is fixed in 6-stable.
> 
> -Alfred
> 
> * Stephen Bartnikowski <sbartnikowski at barkinglizards.com> 
> [081028 09:19] wrote:
> > Hi guys,
> > 
> > To start, I'm not reporting a bug here. I'm trying to get 
> an idea if 
> > I'm on the right track. Also, apologies on the lengthy email.
> > 
> > Oh and this likely relevant. I'm running FreeBSD 6.3 RELEASE that I 
> > installed on July 21. I don't believe any updates have been 
> performed since.
> > 
> > I've got a deadlock situation between a fork call on the 
> main thread 
> > and another thread. I already know I'm venturing into shady 
> territory 
> > when I fork a multithreaded process. However, I don't have a good 
> > understanding of exactly what's going on there, which is 
> where I'm hoping you guys can help.
> > Stack dumps are at the bottom of this email.
> > 
> > Idea 1: Thread #5 blows up and in its bad state is stuck on a mutex 
> > for whatever reason. Thread #1 in the fork call is attempting to 
> > reinitialize each mutex in the process space and deadlocks because 
> > Thread #5 is hosed and has one of those mutexes.
> > 
> > Idea 2: Thread #5 blows up at the same time that Thread #1 
> makes the 
> > fork call. Since at this point in FreeBSD (6.3), the Giant 
> Lock logic 
> > is still in there, and these two threads deadlock each other on 
> > pthread_mutexattr_init calls.
> > 
> > Note that my forked process logic is followed by an execv call, 
> > although I just noticed that if execv fails for whatever 
> reason, I'm 
> > likely doing some unsafe logging calls before that forked 
> process quits.
> > 
> > Any input on whether Idea 1 or Idea 2 are valid?
> > 
> > Thank you!
> > 
> > - Stephen
> > 
> > Here's the main thread (#1) doing the fork call. It's 
> blocked on that 
> > pthread_mutexattr_init call.
> > 
> > #0  0x28109198 in pthread_sigmask () from /lib/libpthread.so.2
> > #1  0x28109148 in sigprocmask () from /lib/libpthread.so.2
> > #2  0x2811360c in pthread_mutexattr_init () from 
> /lib/libpthread.so.2
> > #3  0x281062db in fork () from /lib/libpthread.so.2
> > #4  0x2850e04c in blt::Fork () at wrapunix.cpp:978
> > #5  0x08073e7b in cerebro::ModuleManager::loadModule 
> (this=0x810af40,
> > rModule=@0x816a200) at ModuleManager.cpp:500
> > #6  0x08073f54 in cerebro::ModuleManager::loadModules 
> (this=0x810af40, 
> > mqipctok=@0x80ef134, piddir=@0x80ef124) at ModuleManager.cpp:536
> > #7  0x08064e26 in cerebro::Cerebro::main (this=0x80ef100, argc=4,
> > argv=0xbfbfe9d4) at Cerebro.cpp:721
> > #8  0x08069e6a in main (argc=4, argv=0xbfbfe9d4) at Cerebro.cpp:1934
> > 
> > And here's the second (corrupted) thread (#5), that I'm 90% sure is 
> > caused by a third-party logging library, unfortunately.
> > 
> > #0  0x28114fbf in pthread_mutexattr_init () from 
> /lib/libpthread.so.2
> > #1  0x28110e29 in _pthread_mutex_trylock () from 
> /lib/libpthread.so.2
> > #2  0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2
> > #3  0x2811d3f5 in __error () from /lib/libpthread.so.2
> > #4  0x28110e29 in _pthread_mutex_trylock () from 
> /lib/libpthread.so.2
> > #5  0x28112cc6 in pthread_mutex_lock () from /lib/libpthread.so.2
> > #6  0x2810831a in _spinunlock () from /lib/libpthread.so.2
> > #7  0x289c5d22 in _UTF8_init () from /lib/libc.so.6
> > #8  0x28a42580 in _thread_autoinit_dummy_decl_stub () from 
> > /lib/libc.so.6
> > #9  0x0813c280 in ?? ()
> > #10 0xbf8fda38 in ?? ()
> > #11 0x289c5cc9 in _UTF8_init () from /lib/libc.so.6
> > #12 0x28a2f593 in sys_nsig () from /lib/libc.so.6
> > #13 0x2894e5c4 in ?? () from /usr/lib/libstdc++.so.5
> > #14 0xbf8fd9c8 in ?? ()
> > #15 0x2892db3d in operator delete () from /usr/lib/libstdc++.so.5
> > #16 0x2892db51 in operator delete () from /usr/lib/libstdc++.so.5
> > #17 0x288ed6fb in std::string::_Rep::_M_destroy () from
> > /usr/lib/libstdc++.so.5
> > #18 0x28110e29 in _pthread_mutex_trylock () from 
> /lib/libpthread.so.2
> > #19 0x2811d3f5 in __error () from /lib/libpthread.so.2 #20 
> 0x280fa170 
> > in ?? ()
> > #21 0x00000000 in ?? ()
> > #22 0xbf8fdb64 in ?? ()
> > #23 0x280d46fc in symlook_obj () from /libexec/ld-elf.so.1
> > 
> > _______________________________________________
> > freebsd-threads at freebsd.org mailing list 
> > http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> > To unsubscribe, send any mail to 
> "freebsd-threads-unsubscribe at freebsd.org"
> 
> --
> - Alfred Perlstein
>