Ruby blocks... forever

[Nathaniel Talbott]

Ruby 1.8.1preview2, running on Debian Linux. Server is WEBrick based,
and the main extensions used are Ruby/ODBC and Ruby/Postgres.

I just tried to put the server in to production (approximately an
exponential increase in users, although it was done at a lower-traffic
time of day) and Ruby decided to hang on me. Here's the appropriate
line from top:

PID USER RSS WCHAN FLAGS LC STAT %CPU %MEM TIME
COMMAND
16419 se 15M rt_sigsus 40 0 S 0.0 1.7 24:52 server

Although I'm not sure, I think the WCHAN indicates that the process is
blocked waiting for something to happen. What, I don't know.

I suspect Ruby/ODBC as the culprit, but here are my questions:

1. What could cause such a hang? Where should I even begin looking?
2. The process is still sitting there, doing nothing. Is there any
more information I can get out of it before I kill it?

Thanks,


Nathaniel

<(><

 

[ts]

N> 16419 se 15M rt_sigsus 40 0 S 0.0 1.7 24:52 server

rt_sigsuspend

to it use pthread ?

Guy Decoux

 

[Robert Klemme]

Ruby 1.8.1preview2, running on Debian Linux. Server is WEBrick based,
and the main extensions used are Ruby/ODBC and Ruby/Postgres.

I just tried to put the server in to production (approximately an
exponential increase in users, although it was done at a lower-traffic
time of day) and Ruby decided to hang on me. Here's the appropriate
line from top:

PID USER RSS WCHAN FLAGS LC STAT %CPU %MEM TIME
COMMAND
16419 se 15M rt_sigsus 40 0 S 0.0 1.7 24:52 server

Although I'm not sure, I think the WCHAN indicates that the process is
blocked waiting for something to happen. What, I don't know.

I suspect Ruby/ODBC as the culprit, but here are my questions:

1. What could cause such a hang? Where should I even begin looking?

Database transaction deadlocks

2. The process is still sitting there, doing nothing. Is there any
more information I can get out of it before I kill it?

Hm, dunno.

robert

 

[Nathaniel Talbott]

N> 16419 se 15M rt_sigsus 40 0 S 0.0 1.7 24:52
server

rt_sigsuspend

to it use pthread ?

I can find no evidence that Ruby/ODBC or FreeTDS (which I'm using
Ruby/ODBC to access) use pthreads, although I admittedly do not know
much about how to look. I have no earthly idea whether Ruby/Postgres
uses pthreads, but I suspect it doesn't.


Nathaniel

<(><

 

[ts]

N> I can find no evidence that Ruby/ODBC or FreeTDS (which I'm using
N> Ruby/ODBC to access) use pthreads, although I admittedly do not know
N> much about how to look. I have no earthly idea whether Ruby/Postgres
N> uses pthreads, but I suspect it doesn't.

svg% ldd ruby
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40027000)
libdl.so.2 => /lib/libdl.so.2 (0x40078000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4007b000)
libm.so.6 => /lib/i686/libm.so.6 (0x400a8000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
svg%


Guy Decoux

 

[Nathaniel Talbott]

N> I can find no evidence that Ruby/ODBC or FreeTDS (which I'm using
N> Ruby/ODBC to access) use pthreads, although I admittedly do not know
N> much about how to look. I have no earthly idea whether Ruby/Postgres
N> uses pthreads, but I suspect it doesn't.

svg% ldd ruby
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40027000)
libdl.so.2 => /lib/libdl.so.2 (0x40078000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4007b000)
libm.so.6 => /lib/i686/libm.so.6 (0x400a8000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
svg%

OK, it appears that Ruby/ODBC and FreeTDS's ODBC layer both link to
libpthread (though I don't really understand why; grepping for pthread
in their source turns up nothing interesting). What does that mean?


Nathaniel

<(><

 

[ts]

N> OK, it appears that Ruby/ODBC and FreeTDS's ODBC layer both link to
N> libpthread (though I don't really understand why; grepping for pthread
N> in their source turns up nothing interesting). What does that mean?

This mean that it can exist a thread synchronisation problem, and perhaps
it's best to use the latest CVS version of ruby

Guy Decoux

p.s. : the email address in the Cc: is invalid

 

[Nathaniel Talbott]

N> OK, it appears that Ruby/ODBC and FreeTDS's ODBC layer both link to
N> libpthread (though I don't really understand why; grepping for
pthread
N> in their source turns up nothing interesting). What does that mean?

This mean that it can exist a thread synchronisation problem, and
perhaps
it's best to use the latest CVS version of ruby

OK... do I need to use --with-pthread-ext when I build?

Thanks,


Nathaniel

<(><

 

[ts]

N> OK... do I need to use --with-pthread-ext when I build?

Probably best but this is the option

--enable-pthread

Guy Decoux

 

[Nathaniel Talbott]

N> OK... do I need to use --with-pthread-ext when I build?

Probably best but this is the option

--enable-pthread

OK.

Now, can you or someone else help me understand what this option
actually does? And why, if it's such a problem, it hasn't showed up
before and it isn't on by default? Was every extension linked to
pthread before doomed to lock up eventually?

Thanks,


Nathaniel

<(><

 

[ts]

N> Now, can you or someone else help me understand what this option
N> actually does?

it compile ruby with -lpthread to be sure that the thread system is
correctly initialized.

N> And why, if it's such a problem, it hasn't showed up
N> before and it isn't on by default?

If I've well understood : it not by default because it can cause problems
on some architecture (*BSD ???)

N> Was every extension linked to
N> pthread before doomed to lock up eventually?

Don't expect that one day I can understand pthread :-(

In the distribution of bdbxml, you have

# it's important to have xercesc compiled with -rnone
# (i.e. *without* threads)

because if xerces-c is compiled with pthread you'll see strange problems



Guy Decoux

 

[Nathaniel Talbott]

N> Now, can you or someone else help me understand what this option
N> actually does?

it compile ruby with -lpthread to be sure that the thread system is
correctly initialized.

N> And why, if it's such a problem, it hasn't showed up
N> before and it isn't on by default?

If I've well understood : it not by default because it can cause
problems
on some architecture (*BSD ???)

N> Was every extension linked to
N> pthread before doomed to lock up eventually?

Don't expect that one day I can understand pthread :-(

In the distribution of bdbxml, you have

# it's important to have xercesc compiled with -rnone
# (i.e. *without* threads)

because if xerces-c is compiled with pthread you'll see strange
problems

Thanks, Guy, that helps me understand things better.


Nathaniel

<(><