I’ve been occasionally stumbled upon a strange problem with Ruby’s
threads, that I cannot pinpoint its exact origin. I get occasional race
conditions where the Ruby interpreter consumes all my memory until the
Linux VM goes into action to kill processes (sometimes X11 too!!).
We use Ruby for our Web Application Framework all throughout the
hierarchy (from low-level HTTP handling to higher-level scripting). The
server uses multiple threads to service HTTP requests (one per socket).
Sometimes, and under no particular occasion, the server enters a 100%
CPU loop and consumes all memory until its death. We are taking all
necessary precautions (at least we think we do) to serialize access to
shared data and other critical sections of the code, using the Sync class.
What’s interesting is that this exception pops up in our logs:
Sync_m::Err::UnknownLocker: Thread(#<Thread:0x2040e560 run>) not locked.
Taking a look inside sync.rb, this particular error occurs if the
blocking thread leaving a critical section doesn’t hold the mutex/lock
anymore!!! Any ideas?
We are using Ruby 1.6.8 on Linux and AIX and the error appears (although
not in a reproducable manner) regardless of the platform used. Just for
the records, we use gcc-3.2 on SuSE 8.0 (Linux-2.4.18) and IBM’s XLC 6.0
on AIX 5.2.
Thanks for your time, and sorry of this isn’t the correct place to post
queries like this.
Taking a look inside sync.rb, this particular error occurs if the
blocking thread leaving a critical section doesn't hold the mutex/lock
anymore!!! Any ideas?
Well, the problem is that you don't give enough information.
Can you try to reproduce the error with a small script, and post this
script.
“Elias Karakoulakis” ek@navel.gr schrieb im Newsbeitrag
news:3E461257.20804@navel.gr…
What’s interesting is that this exception pops up in our logs:
Sync_m::Err::UnknownLocker: Thread(#<Thread:0x2040e560 run>) not
locked.
Taking a look inside sync.rb, this particular error occurs if the
blocking thread leaving a critical section doesn’t hold the mutex/lock
anymore!!! Any ideas?
Maybe there’s an error in pairing lock acquisition and release. Maybe you
ignored the result of a try_lock somewhere.
that’s a good suggestion, the return value of try_lock has confused me before.
also you may want to see if another thread has somehow UNLOCKED the sem while
another thread had it. note that unlock returns a value which should be
CHECKED.
-a
···
On Mon, 10 Feb 2003, Robert Klemme wrote:
“Elias Karakoulakis” ek@navel.gr schrieb im Newsbeitrag
news:3E461257.20804@navel.gr…
What’s interesting is that this exception pops up in our logs:
Sync_m::Err::UnknownLocker: Thread(#<Thread:0x2040e560 run>) not
locked.
Taking a look inside sync.rb, this particular error occurs if the
blocking thread leaving a critical section doesn’t hold the mutex/lock
anymore!!! Any ideas?
Maybe there’s an error in pairing lock acquisition and release. Maybe you
ignored the result of a try_lock somewhere.
–
====================================
Ara Howard
NOAA Forecast Systems Laboratory
Information and Technology Services
Data Systems Group
R/FST 325 Broadway
Boulder, CO 80305-3328
Email: ahoward@fsl.noaa.gov
Phone: 303-497-7238
Fax: 303-497-7259
====================================