Date: Tue, 28 Oct 2008 12:32:14 -0500 From: "Stephen Bartnikowski" <sbartnikowski@barkinglizards.com> To: <freebsd-threads@freebsd.org> Subject: RE: deadlock in fork call? Message-ID: <687C5AD700E9484DABB55D5F92A18C10@OCTOBER> In-Reply-To: <20081028164026.GF83037@elvis.mu.org> References: <5B0A3FB3D06E41849325AD3EA98CAD55@OCTOBER> <20081028164026.GF83037@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org] > Sent: Tuesday, October 28, 2008 11:40 AM > To: Stephen Bartnikowski > Cc: freebsd-threads@freebsd.org > Subject: Re: deadlock in fork call? > > I'm pretty sure this is fixed in 6-stable. > > -Alfred > > * Stephen Bartnikowski <sbartnikowski@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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-threads > > To unsubscribe, send any mail to > "freebsd-threads-unsubscribe@freebsd.org" > > -- > - Alfred Perlstein >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?687C5AD700E9484DABB55D5F92A18C10>