Bug #8810

GDBM.open内で処理がブロックしたらTimeout.timeout が効かない

Added by Naohisa Goto almost 2 years ago. Updated almost 2 years ago.

[ruby-dev:47652]
Status:Open
Priority:Normal
Assignee:-
ruby -v:- Backport:1.9.3: UNKNOWN, 2.0.0: UNKNOWN

Description

GDBM.open内で処理がブロックした場合にTimeout.timeoutが効きません。

再現方法は、Solarisにて、以下のようにGDBMをオープンしたままにして、

$ ruby -r gdbm -e 'db = GDBM.open("/var/tmp/tmpdb"); gets'

同一マシンで別のシェルで

$ ruby -r gdbm -r timeout -e 'Timeout.timeout(5) { db = GDBM.open("/var/tmp/tmpdb") }'

を実行しても、タイムアウトすることなく後者のGDBM.openがブロックし続けて終わりません。

Solarisだけでなく、Linux上にて、以下のように無理やりflockを使わないようconfigureしてmakeしたlibgdbm.soを使用した場合でも同様に再現しました。

$ wget ftp://ftp.gnu.org/gnu/gdbm/gdbm-1.10.tar.gz
$ tar xvf gdbm-1.10.tar.gz
$ cd gdbm-1.10
$ ./configure --prefix=/home/xxxxx/gdbm ac_cv_func_flock=no
$ make
$ make install
$ LD_PRELOAD=/home/xxxxx/gdbm/lib/libgdbm.so ruby -r gdbm -e 'db = GDBM.open("/var/tmp/tmpdb"); gets'
(別のシェルにて)
$ LD_PRELOAD=/home/xxxxx/gdbm/lib/libgdbm.so ruby -r gdbm -r timeout -e 'Timeout.timeout(5) { db = GDBM.open("/var/tmp/tmpdb") }'


Related issues

Related to Ruby trunk - Bug #8790: r41424 以降、Solaris と gdbm 1.1.10 にて TestGDBM#test_s_open_lock が終わらない Feedback 08/16/2013

History

#1 Updated by Naohisa Goto almost 2 years ago

  • Subject changed from SolarisでGDBM.open内で処理がブロックしたらTimeout.timeout が効かない to GDBM.open内で処理がブロックしたらTimeout.timeout が効かない

#2 Updated by Motohiro KOSAKI almost 2 years ago

2013/8/22 ngoto (Naohisa Goto) ngotogenome@gmail.com:

Issue #8810 has been reported by ngoto (Naohisa Goto).


Bug #8810: SolarisでGDBM.open内で処理がブロックしたらTimeout.timeout が効かない
https://bugs.ruby-lang.org/issues/8810

Author: ngoto (Naohisa Goto)
Status: Open
Priority: Normal
Assignee:
Category: ext
Target version:
ruby -v: -
Backport: 1.9.3: UNKNOWN, 2.0.0: UNKNOWN

GDBM.open内で処理がブロックした場合にTimeout.timeoutが効きません。

再現方法は、Solarisにて、以下のようにGDBMをオープンしたままにして、

$ ruby -r gdbm -e 'db = GDBM.open("/var/tmp/tmpdb"); gets'

同一マシンで別のシェルで

$ ruby -r gdbm -r timeout -e 'Timeout.timeout(5) { db = GDBM.open("/var/tmp/tmpdb") }'

を実行しても、タイムアウトすることなく後者のGDBM.openがブロックし続けて終わりません。

Solarisだけでなく、Linux上にて、以下のように無理やりflockを使わないようconfigureしてmakeしたlibgdbm.soを使用した場合でも同様に再現しました。

ちらっと見たのですが、これはgdbmを直さないとどうしようもないような
以下コメント付きソースの抜粋。

int
gdbm_lock_file (GDBM_FILE dbf)
{
#if HAVE_FCNTL_LOCK
struct flock fl;
#endif
int lock
val = -1;

#if HAVE_FLOCK // 最初にflockを試す
if (dbf->read_write == GDBM_READER)
lock_val = flock (dbf->desc, LOCK_SH + LOCK_NB); // この時はLOCK_NB使う
else
lock_val = flock (dbf->desc, LOCK_EX + LOCK_NB);

if ((lock_val == -1) && (errno == EWOULDBLOCK))
{
dbf->lock_type = LOCKING_NONE;
return lock_val;
}
else if (lock_val != -1)
{
dbf->lock_type = LOCKING_FLOCK;
return lock_val;
}
#endif

// 次に lockf ためす
#if HAVE_LOCKF
/* Mask doesn't matter for lockf. */
lock_val = lockf (dbf->desc, F_LOCK, (off_t)0L); // なぜか F_TLOCK つけない
if ((lock_val == -1) && (errno == EDEADLK))
{
dbf->lock_type = LOCKING_NONE;
return lock_val;
}
else if (lock_val != -1)
{
dbf->lock_type = LOCKING_LOCKF;
return lock_val;
}
#endif

// 最後に fcntl ためす
#if HAVE_FCNTL_LOCK
/* If we're still here, try fcntl. */
if (dbf->read_write == GDBM_READER)
fl.l_type = F_RDLCK;
else
fl.l_type = F_WRLCK;
fl.l_whence = SEEK_SET;
fl.l_start = fl.l_len = (off_t)0L;
lock_val = fcntl (dbf->desc, F_SETLK, &fl); // こんどはF_SETLKなので待たない

if (lock_val != -1)
dbf->lock_type = LOCKING_FCNTL;
#endif

if (lock_val == -1)
dbf->lock_type = LOCKING_NONE;
return lock_val;
}

Also available in: Atom PDF