more info: I can make this happen at will. I open 2 connections A & B:
A) connects to the database from a C program via the API and runs the
same SP every 30 seconds, the contents of which are:

for select A.AMSMESSAGEID
from TBLAMSMESSAGES A
where A.MESSAGETYPE = 1 and
NOT EXISTS (SELECT 1 from TBLMETERRETURNDATA TR where
TR.AMSMESSAGEID = A.AMSMESSAGEID)
order by A.PRIORITY, A.MESSAGEID
into :amsmessageid
do
begin
amsmessageid = amsmessageid;
end

B) connects to the database and does an update to the AMSMESSAGEID of
TBLAMSMESSAGES . There is only 1 row in this table, it has a
messagetype of 3 and no matching row in TBLMETERRETURNDATA exists.

At the point the update commits the lock manager crashes and the C
program exits.

Note this does NOT happen if I do the update via isql on the same
machine, only when I do it via dbworkbench or development studio over
the lan.

On 03/10/06, Nick Upson <nick.upson@...> wrote:
> I've just (today) upgraded this machine from 1.5.1 to 1.5.3 (classic
> on fedora core 5)
> and ran a program suite that was fine before. I have rebooted since as
> well. There are only 2 client connections in existance. I've run it
> twice and had exactly the same both times (except the number of the
> lock id). At the point where a client updates a record (I think) I get
> the following on the command line the C program is run from
>
> Fatal lock manager error: invalid lock id (35368), errno: 11
> --Resource temporarily unavailable
>
> and below in the firebird.log
>
>
> telensa108.telensa.com Tue Oct 3 14:23:08 2006
> ISC_kill: process 2028 couldn't deliver signal 16 to process
> 3028: permission denied
>
> telensa108.telensa.com Tue Oct 3 14:23:08 2006
> Fatal lock manager error: invalid lock id (35368), errno: 11
>