From: Ezra Zygmuntowicz Date: 2008-04-24T03:19:33+09:00 Subject: Re: Deadlock in DRb On Apr 23, 2008, at 6:11 AM, Robert Klemme wrote: > 2008/4/23, Lars Christensen : >> On Apr 22, 3:45 pm, Robert Klemme wrote: >>> 2008/4/22, Lars Christensen : >> >>>> In a program with two DRb servers running (two time >>>> start_service), i >>> >>> Why do you have two servers? >> >> Well... legacy. I have converted my application to having only 1 DRb >> service started, but the same problem occurs. I still get a deadlock >> after the clients have been connecting for a while. > > Too bad. > >>> For adeadlockyou need at least two resources that are locked in >>> different order. Maybe you have synchronized calls across the two >>> servers thatdeadlock. >> >> My main thread is blocked by DRb.thread.join. All other threads are >> inside the DRb library on either Socket#accept, #read or #write. > > And, are there any locks held? > >> How can there be a deadlock if a thread is waiting in a Socket#accept >> call? As I understand the Ruby deadlock detection is simply fires >> when >> there is no thread to run. >> >>> You could use set_trace_func to trace program execution until >>> thedeadlockand look at the execution flow. >> >> I have tried this, but it doesn't show anything other that the >> deadlock report from Ruby, i.e. that the threads are calling >> Socket#accept, #read or #write and Thread#join. > > These issues are next to impossible to debug without access to code > and an understanding of what the app really does. I'm afraid, I can't > help you further right now. > > Kind regards > > robert What version and patch level of ruby do you have? If you have ruby 1.8.6 and the patch level is less than p111 then you have a faulty ruby interpreter with broken threading that can cause these deadlocks. Make sure you are using ruby 1.8.5 or ruby 1.8.6p11 minimum. Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- ezra@engineyard.com -- EngineYard.com