Hi All,

We are using Firebird CS 2.5.0 on a relatively loaded Centos 64 bit server.
Over the course of the last 2 days, we have had no major problems and
Firebird appears to be performing very well.

System Details:

OS: CentOS release 5.5 (Final) 64 bit (Kernel 2.6.18-194.el5)
Firebird: LI-V2.5.0.26074 Firebird 2.5 (FirebirdCS-2.5.0.26074-0.amd64.rpm)
Attachments: ~200



Earlier today, while attempting to access the monitoring tables via isql, we
received a segfault:

[root@pperfect ~]# isql pperfect
Database: pperfect
SQL> select * from mon$attachments;
Segmentation fault
[root@pperfect ~]#

This segfault occurs when attempting to select from any monitoring table,
has persisted since this morning and is present when connecting via isql
locally or remotely (I imagine restarting the server may resolve it).

We enabled Bugcheckabort and used gdb to analyse the core dump. Below,
please find the result for the offending thread:

Core was generated by `fb_inet_server'.
Program terminated with signal 11, Segmentation fault.
#0 0x00000036b3e7c3c6 in _wordcopy_fwd_aligned () from /lib64/libc.so.6

Thread 1 (Thread 29172):
#0 0x00000036b3e7c3c6 in _wordcopy_fwd_aligned () from /lib64/libc.so.6
#1 0x00000036b3e7a935 in memmove () from /lib64/libc.so.6
#2 0x00002b36ea2d33ff in Jrd::DatabaseSnapshot::SharedData::read
(this=0x2aaaac789cc8, pool=..., resultSize=@0x40cd5848)
at ../src/jrd/DatabaseSnapshot.cpp:171
#3 0x00002b36ea2d7b45 in Jrd::DatabaseSnapshot::DatabaseSnapshot
(this=0x2aaaac800bf0, tdbb=0x40cd6700, pool=...)
at ../src/jrd/DatabaseSnapshot.cpp:472
#4 0x00002b36ea2d834a in Jrd::DatabaseSnapshot::create (tdbb=0x40cd6700) at
../src/jrd/DatabaseSnapshot.cpp:350
#5 0x00002b36ea2daf44 in Jrd::VirtualTable::open (tdbb=0x40cd6700,
rsb=0x2aab3762f2a8) at ../src/jrd/VirtualTable.cpp:157
#6 0x00002b36ea3cd8d8 in RSE_open (tdbb=0x40cd6700, rsb=0x2aaaac838a48) at
../src/jrd/rse.cpp:541
#7 0x00002b36ea343552 in EXE_looper (tdbb=0x40cd6700,
request=0x2aaaac845020, in_node=0x2aaaac838f90)
at ../src/jrd/exe.cpp:2016
#8 0x00002b36ea345f86 in looper_seh (tdbb=0x40cd6700,
request=0x2aaaac845020, transaction=0x2aaaac800d00)
at ../src/jrd/exe.cpp:2943
#9 EXE_start (tdbb=0x40cd6700, request=0x2aaaac845020,
transaction=0x2aaaac800d00) at ../src/jrd/exe.cpp:1076 #10
0x00002b36ea375bbf in JRD_start (tdbb=0x40cd6700, request=0x2aaaac845020,
transaction=0x2aaaac800d00,
level=<value optimized out>) at ../src/jrd/jrd.cpp:6389
#11 0x00002b36ea46b8c7 in execute_request (tdbb=0x40cd6700,
request=0x2aaaac81eff0, tra_handle=<value optimized out>,
in_blr_length=<value optimized out>, in_blr=<value optimized out>,
in_msg_length=<value optimized out>, in_msg=0x0,
out_blr_length=0, out_blr=0x0, out_msg_length=0, out_msg=0x0,
singleton=false) at ../src/dsql/dsql.cpp:1274
#12 0x00002b36ea46c548 in DSQL_execute (tdbb=0x40cd6700,
tra_handle=0x40cd69c8, request=0x2aaaac81eff0, in_blr_length=36965,
in_blr=0x2b36eadeb548 "\005\002\004", in_msg_type=<value optimized out>,
in_msg_length=0, in_msg=0x0,
out_blr_length=<value optimized out>, out_blr=0x0, out_msg_length=<value
optimized out>, out_msg=0x0)
at ../src/dsql/dsql.cpp:271
#13 0x00002b36ea382e4f in jrd8_execute (user_status=0x40cd6aa0,
tra_handle=0x40cd69c8, stmt_handle=<value optimized out>,
in_blr_length=36965, in_blr=0x2b36eadeb548 "\005\002\004",
in_msg_type=0, in_msg_length=50118, in_msg=0x0,
out_blr_length=<value optimized out>, out_blr=0x0, out_msg_length=<value
optimized out>, out_msg=0x0)
at ../src/jrd/jrd.cpp:3739
#14 0x00002b36ea24ca41 in isc_dsql_execute2_m (user_status=<value optimized
out>, tra_handle=0x40cd6b6c,
stmt_handle=<value optimized out>, in_blr_length=36965,
in_blr=0x2b36eadeb548 "\005\002\004", in_msg_type=0,
in_msg_length=<value optimized out>, in_msg=0x0, out_blr_length=<value
optimized out>, out_blr=0x0,
out_msg_type=<value optimized out>, out_msg_length=<value optimized
out>, out_msg=0x0) at ../src/jrd/why.cpp:2707
#15 0x00002b36ea539490 in rem_port::execute_statement (this=0x2b36eadf2358,
op=op_execute, sqldata=0x2b36eadebfa8,
sendL=0x2b36eadeb878) at ../src/remote/server.cpp:2266
#16 0x00002b36ea539bb4 in process_packet (port=0x2b36eadf2358,
sendL=0x2b36eadeb878, receive=0x2b36eadebc88, result=0x40cd7098)
at ../src/remote/server.cpp:3468
#17 0x00002b36ea53beb7 in loopThread () at ../src/remote/server.cpp:5179
#18 0x00002b36ea23f6d6 in run (arg=0x2b36eadec150) at
../src/jrd/ThreadStart.cpp:128
#19 (anonymous namespace)::threadStart (arg=0x2b36eadec150) at
../src/jrd/ThreadStart.cpp:139
#20 0x00000036b460673d in start_thread () from /lib64/libpthread.so.0
#21 0x00000036b3ed3d1d in clone () from /lib64/libc.so.6


One thing to note is that this is the first time that we have spotted this
problem in 2 days of operation, so we cannot be sure if this problem will
reoccur or can even be reproduced.
Has anyone else noticed a similar oddity?


Thanks and Regards,

Richard Johnson
Adept Software