[pkg-firebird-general] SCH_validate error caused Lock Manager Out of Room

Tue Mar 6 23:39:33 CET 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- -=| Aldo Caruso,  6.03.2007 22:16 |=-
> [...]
>  SCH_validate -- not entered.
> 
>  Helen Borrie suggested me that this has to do mainly with conflicts in
> the thread scheduler, which arise when the Linux kernel implements NPTL
> but the firebird package use the old threading model.

Thank you for spending the time to look after the problem.

>  In fact, not ony this problem appears in my Debian server, but also in
> an old Fedora Core 2 server whose Firebird package is not NPTL.
> 
>  As you, Damyan, suspected previously, NPTL has to do with the problem.
> 
>  In a previous answer you told me that, after inspecting the binary with
> the "$ldd fbserver" command, you concluded that firebird-super-server
> build for debian was not NPTL. 

I've found more robust way for detecting whether given binary is
NPTL-capable or not. See below.

> On the other hand, in my debian server I
> have the following situation:
> 
> Debian Etch.
> kernel: 2.6.18-4-686 #1 SMP
> NPTL 2.3.6 ( I got this info with the command "getconf
> GNU_LIBPTHREAD_VERSION" )

Same here (Debian/sid amd64 and i686)

> So, fbserver uses pthread (old model) while the kernel uses NPTL, and
> hence, as Helen says, SCH_validate error can happen, blocking the server
> ( you have to restart it ).
> 
> My question is:
> Why is there only one alternative in Debian instead of two as there are
> in the original .tar.gz or .rpm packages from Firebird Super Server (
> old threaded model and NTPL ) ? Looking at Firebird official download
> page, I found they have two choices for Super Server.

Generally, my intention is to provide only NPTL binaries. Recent Debian
kernels are NPTL-enabled and given that mixing NPTL and non-NPTL stuff
creates problems (as seen from your research), I see no point in
providing non-NPTL binaries.

> If this is the case for Debian, the only solution I have is using
> Classic Server, which, I hope, doesn't conflict with the threading model.

Not at all. Classic is even better on multi-processor machines (but has
no shared cache like -super).

Now. I've downloaded the "normal" and the "nptl" pre-compiled binaries
from sourceforge and tried to find some mark, by which I'd be able to
tell which is which.

ldd output gives no differences. However, inspecting bin/fbserver with
'objdump -T' gives some interesting clues (binaries for i686):

$ objdump -T nptl/bin/fbserver | grep pthread | head -5
08051724      DF *UND*  00000038  GLIBC_2.3.2 pthread_cond_wait
08051734      DF *UND*  0000017a  GLIBC_2.0   pthread_detach
08051744      DF *UND*  00000009  GLIBC_2.3.2 pthread_cond_timedwait
08051a14      DF *UND*  00000031  GLIBC_2.0   pthread_condattr_init
08051a44      DF *UND*  0000014b  GLIBC_2.1   pthread_create

$ objdump -T normal/bin/fbserver | grep pthread | head -5
08051874      DF *UND*  0000017a  GLIBC_2.0   pthread_detach
080518d4      DF *UND*  000000b6  GLIBC_2.0   pthread_getspecific
08051b54      DF *UND*  00000007  GLIBC_2.0   pthread_condattr_init
08051b84      DF *UND*  0000014b  GLIBC_2.1   pthread_create
08051bc4      DF *UND*  0000001e  GLIBC_2.0   pthread_cond_init

This led me to the supposition that the "normal" fbserver links only to
libc symbols, versioned 2.0 and 2.1. The nptl-enabled fbserver also uses
2.3.2 version of libc symbols, which I suppose are the NPTL-enabled ones.

Let's see:

$ objdump -T normal/bin/fbserver|grep pthread|cut -c34-45|sort|uniq -c
     20 GLIBC_2.0
     10 GLIBC_2.1

$ objdump -T normal/bin/fbserver|grep pthread|cut -c34-45|sort|uniq -c
     11 GLIBC_2.0
     10 GLIBC_2.1
      5 GLIBC_2.3.2

Yep. This seems to be it.

Now we only have to find out the output of the above command on
firebird2-super-server:

(cut's -c param uses different offsets, since this is on amd64)
$ objdump -T /usr/lib/firebird2/bin/fbserver|grep pthread|cut
- -c50-61|sort|uniq -c
     16 GLIBC_2.2.5
      5 GLIBC_2.3.2

So it seems Debian's super-server is NPTL-enabled, at least on amd64. It
would be nice if you can confirm this on i686 (I have no i686 machine
that I can install -super on. I use -classic generally).

Since Debian packages (seem to) use NPTL as well as the kernel, another
possible source is the newer GLIBC version used. Perhaps there is some
sort of incompatibility between firebird 1.5.3 and libc6 (2.3.6.ds1-13).
Unfortunately, I think it is not feasible to build firebrid .debs using
older libc.

I believe 1.5 codebase is mostly on "light maintenance" state, meaning
that I suspect noone of firebird developers would want to waste time to
debug/fix the problem. Can you try 2.0? You can find debian packages of
2.0.1rc1 here[1].

I understand that migrating production database to 2.0 may not be an
option to you, but this is the only thing I can think of at the moment.
Perhaps, if you can reproduce the problem in a test environment, that
could be then migrated to 2.0 for the purpose of checking whether the
problem will go away.

	dam
[1] deb ftp://ftp.modsoftsys.net/public experimental main
- --
Damyan Ivanov                           Modular Software Systems
phone +359(2)928-2611, 929-3993              fax +359(2)920-0994
mobile +359(88)856-6067              JID dam at jabber.minus273.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF7e2lHqjlqpcl9jsRAnO3AJ4kX1EiS+GCLBn5eakR30CassRCJQCggZFp
3EXEHjLqG0Yb6iWaeG8ZWLg=
=BAEx
-----END PGP SIGNATURE-----